[Nitro] Nitro/Og exceptions: To raise or not to raise?
arne at arnebrasseur.net
Fri Sep 7 15:55:17 EDT 2007
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
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.
arne at arnebrasseur.net
More information about the Nitro-general