Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: Error Handling

From: rgaither:triad:rr at: 11-Dec-2002 9:37

Hi All, Thanks to everyone who gave some insight into their use of the error handling options in REBOL. It has helped me get off square one about what approach options are available. Thanks, Rod. On Tuesday, December 10, 2002, at 08:12 PM, Brett Handley wrote:
> 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. > > -- > To unsubscribe from this list, please send an email to > [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes. >
Rod Gaither [rgaither--triad--rr--com] Oak Ridge, NC USA