Re: #0:handle_uncaught_error()

• Date: Thu, 15 Feb 1996 15:13:45 PST
• From:
  Richard Connamacher <phantom@baymoo.sfsu.edu>
• CC: slayer@kaiwan.com, moo-cows@parc.xerox.com
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=us-ascii
• References: <96Feb14.110347pdt.19564@silk.parc.xerox.com>

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.

Phantom

Phantom

• Re: #0:handle_uncaught_error()
• From: Pavel Curtis <pavel@parc.xerox.com>

• Re: #0:handle_uncaught_error()
• From: Pavel Curtis <pavel@parc.xerox.com>

• Prev: Re: #0:handle_uncaught_error()
• Next: Re: #0:handle_uncaught_error()
• Index: MOO-cows
• Thread: MOO-cows