"Barry Kelly" <✉eircom.net> wrote in message
news:✉4ax.com...
>
> Not try..except; try..finally. Perhaps the odd
>
> try
> except
> // error condition clean up
> raise;
> end;
>
> where the situation warrants it.
If I read your code right, you want exceptions re-raised to go all the
way up, regardless.
I don't understand it. Exception handlers are there to catch / mask
exceptions. Exception classes are there so that we can distinguish one
type of error from another. But a generic "ERangeError" could come from
anywhere, so in your average exception handling block you'll have no idea
how, why or where the error came from, nor how to fix it.
> NO!! EXCEPTIONS CAN HAPPEN ***ANYWHERE***.
sure, this is why you need an application-level handler as a last line of
defense.
> You don't "expect exceptions", because the state "I don't expect any
> exceptions" *does not exist*.
??? you don't expect them but you don't "unexpect" them... hmmm.... but I
think I see what you mean; you define exceptions as "the unexpected", but
if you raise exceptions explicitly in code then you must already have an
idea of at least a subset of the possible errors. The main problem is,
again, that the exceptions you will receive from certain components or
functions may not conform to the "specific" exception concept defined by
your application error handling strategy.
> I think one best appreciates exceptions when you look at how it (error
> handling) has to be done in the absence of them;
I don't recognise my error handling code from your description. If at all
present, such complications in my code have arisen due to the necessity
of handling exceptions which I have no control over (e.g. from components
or the RTL).
Kristofer