[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The server will abort the execution of tasks for either of two reasons:
First, an error message and a MOO verb-call stack traceback are printed to the player who typed the command that created the original aborted task, explaining why the task was aborted and where in the task the problem occurred. Then, if the call to the handler verb was itself aborted, a second error message and traceback are printed, describing that problem as well. Note that if the handler-verb call itself is aborted, no further `nested' handler calls are made; this policy prevents what might otherwise be quite a vicious little cycle.
The specific handler verb, and the set of arguments it is passed, differs for the two causes of aborted tasks.
If an error is raised and not caught, then the verb-call
$handle_uncaught_error(code, msg, value, traceback, formatted) |
is made, where code, msg, value, and traceback are the
values that would have been passed to a handler in a try
-except
statement and formatted is a list of strings being the lines of error and
traceback output that will be printed to the player if
$handle_uncaught_error
returns false without suspending.
If a task runs out of ticks or seconds, then the verb-call
$handle_task_timeout(resource, traceback, formatted) |
is made, where resource is the appropriate one of the strings
"ticks"
or "seconds"
, and traceback and formatted are
as above.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |