Our study results revealed that some developers have shifted their perspective on exception handling from the intended proactive approach (i.e., how to handle possible exceptions) to a reactive approach (i.e., using exception handling as debugging aids). In addition, some developers dislike being forced to implement exception-handling constructs and therefore, neglect to implement them thoughtfully. Both results explain the poor quality of error handling.

I think the authors have an overly optimistic view of what exceptions provide to the system. The vast majority of exceptions are little more than glorified logging aids: they give you a message and might contain a stack trace, but that’s about it. What you can't do (without an awful lot of work) is ascertain enough information to go about a reasonable recovery strategy. In particular, it is rare that the immediate caller of an operation that may throw an exception even has enough information to do anything about it. About the only reasonable thing to do is try the operation again.

Furthermore, is there any reason to believe that developers ever viewed exception handling as proactive? Just because it may have been intended as a way to handle possible problems does not mean that it was accepted (or even presented) as such.

Lastly, I posit that the remark to "implement them thoughtfully" is another instance of "boil the ocean".

(Note: This is what prompted my tweet earlier.)

On August 18, I successfully defended my PhD thesis entitled Structuring data via behavioural synthesis. I explored the idea of deriving data structure for objects in a system by examining the behavioural aspects of a system. I did all the programming for the work in Common Lisp and did three things in the thesis to demonstrate how behavioural synthesis can work.

The first was a framework for defining data types whose instances can change their internal structure to accommodate different conditions related to their usage. This is done at the individual object level. It allows for highly adaptive objects, but incurs significant overhead. This demonstrated using limited context to control structural changes.

The second approach used this framework to expand the contexts detected. In particular, I showed how you can define data types that are the union of other data types, possibly with intersecting interfaces. By considering where an object is created in the code and what is on the system stack, code is generated to capture this context. By putting the context directly into the code, the overhead of detecting the conditions in the objects is removed.

Finally, I demonstrated a more open-ended approach that offers up some interesting future work: building class hierarchies on-the-fly. The idea is to write programs without class definitions, but still use classes and objects. I augmented a Lisp system to handle three cases: no class defined, no slot defined and no method found. Using various clues, I come up with a class hierarchy and try it out. There are various limitations to the approach (no surprise!) but it's really interesting and worth some future study. That said, there are certain conditions where it produces reasonable class hierarchies.

The external examiner on the thesis was Richard P. Gabriel, who asked some good questions and gave me some ideas with what to do next with the work. In general, I got the impression the examination committee liked the work, even though it was imprecise in some areas. There are only some minor revisions to make before officially submitting it to the university.

I'm in the process of making the code available — it needs some serious clean-up in places — along with a tech report of the work. When I have the revisions complete and its been submitted to the university, I'll post a copy of the thesis online. Some may be interested in the introduction and literature survey. (One examiner said I should look at publishing the survey.) The more ambitious can dive into the technical elements.

I submitted a paper to the European Lisp Workshop at ECOOP 2008 and got notice that it was accepted! I'm glad to say that the reviewers provided constructive feedback and didn't write terse, dismissive reviews.

The paper is entitled Adaptive libraries and interactive code generation for Common Lisp and builds on some work I presented at ILC 2007. It is joint work with my thesis supervisors. The paper describes a library for an abstract data type (called a dynamic abstract data type or DADT) whose instances represent multiple abstract data types. When the code is evaluated, instances of the DADT note what operations are done to them and where those operations take place in the source code. Most importantly, when these instances are created, they note where in the code they were created.

In some cases, operations may be ambiguous, in which case the programmer is prompted to indicate which data types the operation is to be applied to. This takes place in the context of a certain place in the code and is remembered for disambiguation purposes in the future.

After the profiling information is analyzed, instances of the DADT are grouped together based on where in the code they were created and a specific type is generated for that place; the type is just a class with a slot for each structure inside the DADT instances that were actually used. Code to operate on that type is also produced.

The code generated is not inserted automatically, however (although there is no reason it couldn't be). Instead, the code is given to the editor to present to the programmer in much the same way as a macroexpansion. The reason for this is that the indicators of where in the source code things happen is actually provided by the editor and not the compiler. The reason for this was to make the changing of places less sensitive to edits. This way, the code generation scheme fits better with the usual workflow of Lisp programming.

I'm in the process of adjusting the paper based on the reviewers' comments, but here is a draft version of the one I submitted, if you're interested. I'll also post some code for this once I've submitted the final version (due July 11). I'm also putting together my thesis and gearing up to start a new job, so I'm rather busy of late.