www.talios.com

Sick of the caught/uncaught exception arguments? Try caught/uncauch casting with RuntimeObject's for a change...

I've been toying with writing various versions of my "uber simple" rule engine in java, smalltalk, python, and ruby and the process left me firm in mind that my biggest pet hate with java is not so much thats its strictly typed, but strictly compiled.

What I mean by this relates back to the whole caught/uncaught exception argument, which will invariably bring up java's Exception vs RuntimeException model. Any exception with extends Exception will be picked up as an error by the compiler if not caught in a try/catch block, whilst those which extend RuntimeException are silently ignored and only show up (surprisingly) at run time.

What if this model of ignorance was extended to the Object class? The ClassCastException itself is a RuntimeException, yet we have to explicitly cast at compile time. Under current JDKs, frameworks like to return Object as an abstract base from which we wire things up, but this just leads to pointless casting:

UserValue user = (UserValue) standardDatabaseQuery(
  "SELECT * FROM users WHERE id = 1",
  new UserValueMapper());

In this trivial example, we call a standard method to access the database, building an object with a UserValueMapper class, WE know this returns a UserValue, so that's what we assign, but the framework returns Object, so we play parental minder and cast it.

But what if we introduced a new RuntimeObject class/interface that relaxed the requirement for compile time casting. As well as eliminating the object casting, the java compiler could inject a reflection based method call for any operation on the RuntimeObject (the sooner the object is bound to a strict type the sooner we could revert to whatever traditional method call operation javac generates).

Using the above scenario, the default objects for Map/Set/Runnable could be replaced with RuntimeObjects, letting the developer write things like:

public void doSomethingWithARuleMap(Map rules) {
  if (map.get("nameIsMark").check("mark")) {
    // do something
  }
}

Because the Map returns a RuntimeObject, the call to check() is reflected, and a suitable MethodNotFoundException could be thrown as runtime (I believe such an exception already exists somewhere) if the Map contained an unexpected class.

I don't know how hard this would be, or if its a viable approach, but the code is certainly ALOT cleaner than the crap I've seen with generics, with the added bonus that it puts us a step closer to other dynamic langauges.

I'm not saying we could call java "dynamic" with this change, maybe just "flexable"?

Comments (2)