[REBOL] Re: Error Handling
From: brett:codeconscious at: 11-Dec-2002 12:12
Hi Rod,
> 1. Who is using try, disarm and the error! object?
>
> I haven't yet written anything for someone else in REBOL
> and thus haven't dug into them myself.
I do occasionally. I haven't used error handling as much as I should have.
Initially I was being lazy in trying to understand what was available to me
and how I wanted to use it.
> 2. If you are using the error handling features what are
> your opinions of them?
>
> From reading the documentation there are some things
> I like such as packaging the error in an object and being
> able to extend the known error list.
>
> Thoughts -
>
> 1. I don't generally like the "try" approach in managing
> errors.
I met a "try" approach with Delphi. I loved this because it was the first
time I had real confidence that if I wanted to catch everything, I could.
After my experience with Try in Delphi I was glad when I saw TRY in REBOL.
> It seems that to do it with any thoroughness you
> have to "litter" your program logic with distracting bits of
> tests and syntax.
>From my point of view, errors are part of the variety in the problem space
our programs have to deal with. So they have to be managed somewhere. If I
want to make resuable code, the bit that "makes sense" of the error really
needs to be "close" to the bit that handles the code that generated the
error. So I feel what seems like "litter" and what is does not depends on
your application and its purpose.
> In the case of such a dynamic language
> as REBOL you may be able to mitigate that effect by using
> more data to code processing that puts that extra syntax
> in there for you. Another option would be to replace key
> language constructs with ones that conform to your own
> framework and error handling setups.
It makes sense to have a reusable error handling methods/constructs for
specific situations.
> 2. What I would like to see is an event driven approach to
> errors. The environment could define specific error types
> as events that handlers could be attached to, preferrably
> with a hierarchy of chained responses so handlers could
> be written from the detailed to the general. When combined
> with introspection a very nice job of error handling can be
> done yet the handling doesn't intrude on the logic and
> syntax of the normal processing.
Delpi had a TRY / EXCEPT construct. The code in the TRY was performed and if
an error was generated it could possibly be trapped by a handler in the
Except. The Except could have multiple handlers - which would react based on
the class of the error. Unhandled exceptions would bubble out. Errors could
be re-raised allowing local handling of resources and then higher level
handling as well. I don't think it would be too difficult to add a
try-except to REBOL. I suspect it would be possible to make it a mezzanine
too.
In my opinion this scheme worked fairly well. Exceptions relevent to the
code would be handled near the code, other stuff would be handled further
up. At the very top level of my application I would have a catch-all
handler. Any errors making it this far up were pretty much application
errors. In any case, the application never failed for the user.
Regards,
Brett.
