[Prev][Next][Index][Thread]

# Re: #0:handle_uncaught_error()

- Date: Thu, 15 Feb 1996 15:13:45 PST
- From:
- 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

Follow-Ups:

- Re: #0:handle_uncaught_error()

- From: Pavel Curtis <pavel@parc.xerox.com>

References:

- 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

Home | Subject Index | Thread Index