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

Mark Van De Vyver mvyver at gmail.com
Fri Sep 7 19:58:18 EDT 2007


Hi Arne,
On 9/8/07, Arne Brasseur <arne at arnebrasseur.net> wrote:
> 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.
>

I'd tend to agree.

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

Yes, this would have helped in my case, but....

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

you're right.  It'd be brave to predict how Nitro/OG will be used or
(in my case) abused.
Most people would be building on top of OG, so I imagine they would
rather not have to catch umpteen different exceptions.  With one
possible exception ;-)....

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

No, keep them coming.

> Personally I think exceptions make the most sense if you properly layer
> your library/application.

Would it be stretching things too far to say that _fully_ and
_properly_ (don't ask me to define those) spec'd code is in much
lesser need of exception handling? ()I'm not claiming there is no need
for it, just a lesser need to have it through out the code, it may
still be important at the last layer?)
>From my impression of what spec's tend to do... the result is that for
someone writing code and 'dealing with' a low level/internal OG method
or object, the approach/advice might be: Rather than relying on
handling exceptions in their code, they would be best advised to check
their code can handle all the behavior that is spec'd for that OG
method or object.
So the exception handling is done at write time rather than run time -
am I way off the mark?  Spec guru's? (maybe this now off-topic?)

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

Sounds nice :)

> 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'd agree with that.  I think people would be more comfortable with
this knowing that the code was 'fully' spec'd - what this is, is
probably a moving target.

The possible exception I mentioned earlier.... where you use a package
that throws exceptions you should rescue those?  Let anything else go
through?
I'm not familiar with Facets and what it does - I suppose a good time
to look into that is soon.

Another possibility is to only place exceptions in a particular layer
of code, say the last layer(s).  This too you'd probably only be able
to do with some confidence once and the behavior was set out.  In the
case of OG this would mean og.rb and/or the vendor adapter ruby files.
Any strong opinions?

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

Unless I'm way off the mark with my previous comments.... I'd be
inclined/happy to keep exceptions out of it as much as possible (nice
vague statements), relying on the specs to guide people on how to use
the objects and methods, and what to except from them.
This would probably mean asking the current (low level) users and spec
writers to tough it out in the mean time.

Also, let's face it, I don't see this list full of people emailing
with tails of woe about unexpected/unfathomable failures/behavior, so
it seems the code is pretty well proved.
Leave aside some instances of me mis-using some OG objects out of ignorance :)

Cheers
Mark

> (ab)
>
>
> --
> Arne Brasseur
> http://www.arnebrasseur.net
> arne at arnebrasseur.net
>
>


More information about the Nitro-general mailing list