[Nitro] Nitro/Og exceptions: To raise or not to raise?

[Arne Brasseur]

Mark Van De Vyver schreef:
> Hi Devs,
> Following up on some 'issues I ran into with trying to spec an adapter.....
> I noticed that exceptions are _almost_ never raised in OG.
> Is there a policy?
> Is there a style/structure that should be following?
> Is there a significant performance cost?
>   
This is not an easy subject, it has lots to do with development culture 
and philosophy. Books have been written on this. Also I'm not closely 
familiar with the Og code.

My most humble personal opinion is that if you start raising exceptions 
you need clear conventions about it. Exceptions are part of the 
interface, it should be clear to the programmer which methods can raise 
which exceptions.

C-style programming has always done without exceptions, just wrapping 
every non-trivial method in an if to see if it failed. Essentially it's 
the same thing, but the programming interface differs.

The down and upside about exceptions is that they propagate up the 
stack. This is good because it follows the 'fail early' rule. The 
application will immediately fail if nothing is done about the error, 
instead of carrying on with possibly corrupt data. The developer gets 
early feedback, close to the source of the error.

This can also be bad in production because when the error is 
non-critical it causes the whole application to fail, instead of 
carrying on. Unless you're doing banking or rocket launching it can be 
OK to have an application do a 'best effort'.


As I said I'm not closely familiar with the Og code, I'm just spitting 
some random thoughts. Sorry for any conceived noise.

Personally I think exceptions make the most sense if you properly layer 
your library/application. For every layer make an exception superclass 
for that layer. In the layer(s) above, always catch exceptions from 
below, possibly wrapping them in an exception for the current layer and 
raising them again. This way your interfaces stay cleanly separated... 
But then again imposing too many rules might seriously hamper developer 
creativity. I usually take the view that too much up front thought about 
error handling just makes the code more complex. Let the code prove 
itself, add error handling for areas where it shows (or it's really 
obvious) that things can go wrong. After all you could check for 
insufficient memory after every call, but it wouldn't be very useful.

I think virtually every programmer has their own thought about this, I'd 
love to hear what others on this list think.

(ab)


-- 
Arne Brasseur
http://www.arnebrasseur.net
arne at arnebrasseur.net