Programmer’s problem: EXPECT EXCEPTIONS OR EXEMPT EXCEPTIONS?

Let me classify computer software in two buckets

1.        Controlled: All components of entire system are known and contract bound – they know each other to pass or refer information or synthesize inputs to each other.

2.        Open: Where software is “lent” or “provided” either in market place or in cloud without knowing who or how it is going to be used.

One argument – At the least in controlled environment, exceptions are programming errors and therefore such exceptions should never occur in the code ever. Only systemic errors such as OutOfMemoryError, StackOverflowError, must be coupled with published error codes, compensating actions and notifications for “right” restart points in process must follow.

Programming errors occurs when

·         Developers did not test full range of possibilities.

·         Failed to install a “compensating” action.

·         Program operated beyond a “contract”

·         poor/ungoverned interfaces are at play.

Counter argument – User retrial initiation is a UX offence and denial of service. Exceptions are code level adjustments and are internal. As long as business workflows are not affected, exception management in the code is a must and normal.

Honestly, I could not resolve the “code purism” versus “Business Continuity” paradigms. Both have their place under the sun.

Instead, I stared at possibilities of code control on very common exceptions in Java and Python (this is for illustration and not exhaustive):

After sieving through nearly 30 of them, I did not find a compelling case to hold developers guilty. This is what generally happens : Either their vision was not beyond the present code or they imagined much more than the reality. I found the onus on Software Architects instead.

If the “architecture quantum” is defined right, if the “fitting functions” on quality of interfaces and coupling are robust, if “functional cohesion” is ensured by a good inter component contract, if “guarantee of delivery” from a unit program is adhered, if the organizational “Condition axioms” shadow the policies the business continuity is coded already.

BTW – the jargons in parenthesis in the sentence above, do have elaborate meaning and responsibilities in software Architecture.

Many of my contacts said they never understood what architects do really. That is one way of describing what software architects do or should do?  Very well.

Then I am continuing to wonder on “open” software…..I don’t know if documentation should cover the possibilities, or common sense prevails or loose-trust-on-problem-discovery-on-the-run is alright..or keep the functionality so minimal, that modular function does what is just expected? No answers yet.