Error Handling

RG> here are some questions and thoughts on error handling RG> in REBOL. RG> Questions - RG> 1. Who is using try, disarm and the error! object? I do it very often. For example this is from my recent IRC client: try-do: func[action][if error? set/any 'err try [do action][bot-error disarm err]] bot-error: func[err /local type id arg1 arg2 arg3][ set [type id arg1 arg2 arg3] reduce [err/type err/id err/arg1 err/arg2 err/arg3] cprint/err [ "Bot-" system/error/:type/type ": " reduce bind system/error/:type/:id 'arg1 ] cprint/err ["** Where: " mold err/where] cprint/err ["** Near: " mold err/near] ] =( Oliva David )=======================( [oliva--david--seznam--cz] )== =( Earth/Europe/Czech_Republic/Brno )============================= =( coords: [lat: 49.22 long: 16.67] )=============================

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.

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.

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.

It makes sense to have a reusable error handling methods/constructs for specific situations.

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.

Rod Gaither [rgaither--triad--rr--com] Oak Ridge, NC USA

And Maarten's post of Ernie's HANDLE showed some it. Some very handy stuff too which made me think some more on error handling ideas. Here's a few variants that might be interesting. They are obviously exploratory ideas not long-time tested concepts/scripts. Not sure of the usefulness of them but here they are... Sorry about line-wrapping of my verbose function doco. ; 8<------------------------------------------------------ REBOL [ Title: "Error handling possibilities." Author: "Brett Handley" ] on-error: func [ {Tries to DO a block or if an error DO handler.} [catch] block [block!] handler "If handler is a block! then ERROR, RESULT, BLOCK and HANDLER will be bound." /local result error ] [ if error? set/any 'result try block [ if block? :handler [ error: disarm result bind handler 'result ] set/any 'result do handler ] get/any 'result ] any-success: func [ {Tries to DO each block of a series and returns the first value that is not an error.} [catch] block [any-block!] /local result ] [ result: none repeat expression block [ if not error? set/any 'result try expression [break] ] get/any 'result ] until-success: func [ {Tries to DO the block and will continue retrying until the evaluation completes without an error.} [catch] block [any-block!] delay [time! block! none!] "Delay time or expression to DO before trying again." /local result ] [ if time? delay [delay: does compose [wait (delay)]] result: none forever [ if not error? set/any 'result try block [break] do delay ] get/any 'result ] ; 8<------------------------------------------------------ ; EXAMPLES ; ON-ERROR ; A (smaller) variation on Ernie's HANDLE. It allows the ; handler block to return a value. ; The handler just eats the error on-error [1 / 0] [] ; The handler returns a value where the first block fails. on-error [1 / 0] none on-error [1 / 0] ["Success"] ; The handler re-raises the original exception. on-error [1 / 0] [ print "do something important." result ] ; The handler has access to the disarmed error and ; Reinterprets math errors into a user error, other ; errors are just re-raised. A function is used here ; to demonstrate both cases. test-func: func [code] [ on-error code [ either error/type = 'math [ make error! "You shoulda saw that coming!" ] [result] ] ] test-func [Print "math error" 1 / 0] test-func [Print "bad arg type" read [asdfjkl--lksdfkl]] ; ANY-SUCCESS ; Try a few things - one of them should work... any-success [ [1 / 0] [read [asdfjkl--lksdfkl]] ["Success"] ] ; UNTIL-SUCCESS ; A simple delay, until finally success. k: 0 until-success [ print "trying..." if lesser? k: k + 1 4 [1 / 0] "Success!" ] 00:00:01 ; A complex delay. ; Breaking from the delay block returns the last error. k: 0 until-success [print "Trying..." 1 / 0] [ if greater? k: k + 1 4 [break] wait 00:00:01 ]