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

[REBOL] Centralise error trapping in REBOL/View applications

From: rudolf:meijer:telenet:be at: 5-Aug-2007 16:41

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] [ 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