MOO-cows Mailing List Archive


Re: #0:handle_uncaught_error()

Pavel Curtis wrote:
> > Well, I had a web server being connected to an object and I wanted to nicely
> > format the traceback messages for the web so the person can see the
> > traceback if they are testing their objects, was easy enough to check that
> > in #0, but I was wondering why it wasn't called on the object like some of
> > the other system-related verbs.
> The question is, what's the general rule for which object to call when an
> arbitrary MOO task raises an uncaught error?
> In your case, anyway, I wouldn't use this mechanism at all; I'd wrap a `try
> ... except v (ANY) ... endtry' around the call to the code in question and do
> the formatting of the traceback in the `except' part.

Does the TRY struct catch task running out of ticks/seconds errors?  TRY works 
great for me, but my main concern is what if the task runs out of ticks?  I need 
to be able to recover from that, and hacking at #0:handle_task_timeout (if i got 
that verb right) seems messy.  I guess the general rule for which object would 
handle it would be which object's connection would be the one to see the 
traceback.  If a timeout traceback would be sent to a connection coming through 
#123, then #123 would be the object to handle that traceback.



Follow-Ups: References:

Home | Subject Index | Thread Index