Thu Feb 28 15:40:47 CET 2008
prompt and errortrace
trying to get some decent stack trace reporting working for sandboxed
evaluators. first thing: extended the evaluator with a preprocessor
that takes 'unquoted' commands. see make-eval in snot/box.ss
now: where do exceptions go that are generated in the box? it seems
they are propagated across the box barrier. do i want that? yes, in
case of normal eval, but no in case of repl.
maybe look at the sandbox plt code to see if it uses prompts..
NOTE: exceptions travel across prompts. this is because they are
re-raised. see the internal function 'user-eval' in
'make-evaluator*' in scheme/sandbox.ss : the value that comes from
the channel is raised if it's an exception.
in order to capture stack traces, it needs to be done inside the
sandbox, since the outside doesn't have access to this (it's a
something else i noticed there: void can be used to capture anything:
(with-handlers ((void (lambda (ex) 123))) (raise 'boo))
10.2.2 handling exceptions:
"The new exception handler processes an exception only if one of the
pred-expr procedures returns a true value..."
it doesn't say anything about void values. maybe some unspecified
legacy thing? ok.. maybe time to stop. a 'true value' is not a '#t'
value. void is true.
anyways.. looks like the solution is (see brood ramblings) to capture
the exception inside the box, and have it print an error trace
there. it should be possible to use the default error printer for
this. if i'm correct, the exception contains the complete information
to print a stack trace.
"The default error display handler displays its first argument to
the current error port (determined by the current-error-port
parameter) and extracts a stack trace (see
continuation-mark-set->context) to display from the second argument
if it is an exn value but not an exn:fail:user value."
fixed that: solution is:
* errors are captured inside the box by the plt sandbox.ss machinery
* they are printed with-error-print using (error-display-handler)
(used in language.ss)