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.)

“The ability to reduce everything to simple fundamental laws does not imply the ability to start from those laws and reconstruct the universe.”— Philip Warren Anderson, More is Different

Something I have noticed in my time developing, reading about and researching software is the pervasive idea that because we can control the workings of small components, controlling large components is much the same. This can be seen in statements such as “all we need to do is hook A into B and we’re done!”

Unfortunately, there is some point at which the combination of components becomes an unwieldy mess and the ability to understand what is going on is effectively beyond its creator’s grasp.

Software development tends to happen by envisioning the system that you want to create, breaking it down into smaller components, making those components and then stitching them together. This kind of top-down approach is reductionism at work, something I rarely find gets acknowledged, and suggests to me it is taken for granted. I suspect it goes unacknowledged because of a tacit assumption that software can be written from a specification purely by deductive reasoning, a sentiment succinctly espoused by C.A.R. Hoare back in 1969:

“Computer programming is an exact science in that all the properties of a program and all the consequences of executing it in any given environment can, in principle, be found out from the text of the program itself by means of purely deductive reasoning.”

This assumes that “what goes down must come up”. It’s as if deconstruction is enough to predict the outcome of construction. That seems perversely arrogant.

Using reductionism to design and build software isn’t inherently wrong. What’s wrong is assuming that it’s sufficient. Part of the reason that it’s not sufficient is that when stitching the parts together you need a thorough, if not complete, understanding of the all the components in the environment in which the computation is taking place. In practice, it’s rare that you know what those components are and even if you do, many of them are physical and prone to failure or conscious and prone to whimsy.

Since it’s hard to know all the ways your components can be affected, when they get connected, this is the point at which the unwieldy mess starts to take hold and the illusion of control sets in.

What would it take to build software by giving up the control we may not have anyway? Is there more to it than genetic algorithms?