Re: Press Release - Ada 2012 Language Standard Approved by ISO

[sbelmont700@gmail.com]

This is just one programmer's opinion based on what I've seen in C++ and Java, but exception specifications are a bad path that goes nowhere.

Consider the static case, where a subprogram has to specify a superset of all the specifications of subprograms it calls.  This will be of limited value, since you almost always end up being coupled to an API that you don't have control over (gtkAda, Claw, etc), which are written pre-2012 and are not likely to be updated anytime soon.  Unless they are painstakingly revised to change the default "raises anything" (which is not going to happen, since you cut out all pre-2012 customers), then all the subprograms that call them must also 'raise anything', and those that call those must 'raise anything' as well in a viral nature, and so on and so on for everything, and you end up with all subprograms raising everything, and it's a lost cause.  The dynamic case (as in C++) is just as bad, since when an unspecified exceptions happens, the only thing left to do is continue erroneously or obfuscate things by raising a different exception than what originally happened, and you're actually worse off than before.

Secondly, the point is moot for OOP since the goal is to use classwide types.  Putting an exception specification on a parent type automatically restricts all the child types (which may not even be thought of yet, much less written) to following that same model, which is often not the case.  Similar to the guideance of making the controlling operand 'in out' to anticipate future child types that might need to make state changes, any parent type would be unwise to dictate what exceptions a future child implementation might need to raise by putting anything other than a 'raises anything'.  So even if you could put perfect exception specifications on everyting, once you start dealing with the classwide type, it's all out the window anyway.

Finally, IMHO, exceptions are NOT a property of the interface but of the implementation (we will likely have to agree to disagree on this).  You can take a subprogram that works one certain way (and potentially raises one set of exceptions), and then rework the guts to work an entirely different way but produce the same output with the same inputs, and raises a whole new set of exceptions; e.g. if you allocate and free your variables instead of declaring them, that changes the subprograms interface because now you might raise STORAGE_ERROR?  That's a side effect of the implementation, not a change to the interface.  Otherwise, you would have to go back and update the interface nearly every time you change the implementation, which defeats the purpose.

I'm of the school of thought that says every subprogram has just one inherent contract when it comes to exceptions: as long as all the parameters and pre/post conditions are met, the subprogram will *never raise anything*.  Or, to put it another way, an exception is an indication that the contract with the interface has NOT been met.  You don't need to know which ones may or may not be raised, since as long as you meet the pre-conditions they won't ever happen anyway.  If you think you need an exception specification, then IMHO what you really need is another precondition.

Just my $0.02

-sb