Centralise error trapping in REBOL/View applications

In REBOL/View applications distributed as one or more REBOL script files together with REBOL/View itself, it is inconvenient for the end user if residual programming errors lead to system halt with the command window open. The try [block] facility for error trapping is available to avoid this, but it is not feasible or convenient in general to apply this on all blocks that might cause an error. Nor do most REBOL/View applications compute one single top-most function whose result should be trapped. Rather, such applications consist of one or more "layouts" (windows), each of which has a number of "handlers", i.e. functions that are invoked by user action. e.g. clicking a button or other "widget" (control). The number of such handlers can easily run to twenty or more, but they are probably the most natural unit of error trapping. Still, because of the number, it is even more convenient to centralise all error trapping in one master-handler . Thanks to REBOL's ability to manipulate function names and values, this is not difficult to realise. Simply replace each action [handle-xxx] in the layout specification by [handle "xxx"] (xxx being the meaningful part of the handler name). The basic specification of function handle is as follows: handle: func [suffix [string!] /local handler result] [=09 handler: get to-word join "handle-" suffix either error? set/any 'result try [handler] [...report error in some useful way, using disarm result...] [...use result directly if needed, or continue...] ] The use of set/any makes this work even for handlers that do not return a value (there was a thread about this som time ago). Note: since all handling is passed by one central function, any parameter passing by the individual handlers is constrained to be uniform. This is not a major restriction, since the "natural" parameter which is the face object can have any data associated to it in the face/data variable of the object. With that, the function heading becomes: handle: func [suffix [string!] face [object!] /local handler result] and the calls become: [handle "xxx" face] Rudolf W. MEIJER rudolf.meijer-telenet.be

If the only reason for the error handling is to prevent the end user from seeing the error, this is a crude workaround that I've used every once in a while. Just stick it at the beginning of the initial script: if unset? get/any 'RandomUnusedVariable [ RandomUnusedVariable: true ;So the next line doesn't get stuck while [error? Err: try [do read %Start.r][ write %Errors.txt join mold disarm Err {^/^/} ] ] (Start.r being the initial script in this example) Typically, (That is, with nearly all of my scripts) the error message seems to be just as detailed as if the 'try was in the script itself. On Sun, 2007-08-05 at 16:41 +0200, Rudolf W. MEIJER wrote:

2007/8/5, Izkata <Izkata-comcast.net>:

> once in a while. Just stick it at the beginning of the initial script:

Yes, this is what I normally do: window: layout [...] if error? set/any 'error try [ do-events ][ print mold disarm error ] Anton.

I appreciate all the comments received on my suggestion, but would like to say that my point was twofold: to highlight the manipulation ability of REBOL, allowing to dynamically compute a function name [handler: get to-word join "handle-" suffix] and the more accurate error-logging that is made possible by trapping errors at handler level rather than at <view layout> level. BTW, if one wants to have the equivqalent of [try [view layout]] with RebGUI, where the windows application is started by [display title window] followed by [do-events], I suppose the trap is on the latter function: [[try [do-events]]. Right? Rudolf Meijer

Rudolf W. MEIJER napsal(a):

> I appreciate all the comments received on my suggestion, but would like > to > say that my point was twofold: to highlight the manipulation ability of > REBOL, allowing to dynamically compute a function name [handler: get > to-word > join "handle-" suffix]

> and the more accurate error-logging that is made > possible by trapping errors at handler level rather than at <view > layout> > level.

> BTW, if one wants to have the equivqalent of [try [view layout]] > with > [do-events]]. Right? > Rudolf Meijer