guile-devel
[Top][All Lists]
Advanced

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

R6RS exception printing -- take #2


From: Andreas Rottmann
Subject: R6RS exception printing -- take #2
Date: Tue, 01 Feb 2011 01:19:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Hi!

I've started refreshing the patch[0] to improve exception presentation for
R6RS exceptions, initially discussed in [1].  I'd like to solicit
clarification on a few points.

To recap, it was agreed to add something like the following internal API
to boot-9.scm:

  exception-printer := port key args exception-printer -> nothing

  set-exception-printer! : key exception-printer -> nothing
  exception-printer : key -> exception-printer OR #f

In the above, exception-printer is a procedure that's supposed to either
display the exception it got passed (via `args') on `port', or "punt",
by calling the exception printer passed to it.  Note that, relative to
the previous discussion, I've added the argument `key', to make it
possible for the fallback (generic) exception printer, as passed to any
registered exception printer as its last argument, to display the key of
the raised exception.  Another option (which I slightly prefer) would be
this change, relative to the above API:

  exception-printer := port args thunk

In this variant, the exception printer may call `thunk' to punt on
handling the exception -- the `key' argument is not necessary anymore,
as it can be closed over by the thunk.

This exception registry would be used in the REPL error-handling code
primarily, via a `print-exception' procedure querying the registry and
invoking the matching printer (or the default one, if no printer is
matching).

Another open issue is the potential `frame' argument; it seems this is
only used at one place in `(system repl error-handling)', inside
`call-with-error-handling' (I did a quick grep for "display-error" and
"Throw to" to identify the sites where I'd plug in the exception
registry via the `print-exception' procedure).  

If we decide that `frame' should not be part of the exception-printer
arguments, we'd lose source information in the exception printout in
this case.  As `call-with-error-handling' is only used in the REPL
(where one could get source information via the ",bt" meta-command) and
in `(web server)', I guess the loss would be bearable.

[ Just a thought: it looks like it /might/ make sense to contemplate
  deprecating passing the frame information to `display-error' and
  untangle displaying the exception object and displaying a backtrace
  completely. ]

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]