[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: R6RS exception printing -- take #2
From: |
Andreas Rottmann |
Subject: |
Re: R6RS exception printing -- take #2 |
Date: |
Sun, 06 Feb 2011 19:09:34 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Andy Wingo <address@hidden> writes:
> Heya Andreas,
>
Hi! I've attached an updated patch; see below for some points that are
still to be discussed. If this patch is deemed OK, I'll work on
converting all relevant sites in the REPL to use `print-exception'.
> You proposed a choice between two options:
>
> On Tue 01 Feb 2011 01:19, Andreas Rottmann <address@hidden> writes:
>
>> exception-printer := port key args exception-printer -> nothing
>> exception-printer := port args thunk
>
> The `key' argument is necessary, at least if you want one printer to
> handle multiple keys (as the default printer might). I prefer the
> first, FWIW.
>
OK, I've now done this:
exception-printer := port key args thunk -> nothing
The rationale of passing in a thunk instead of an exception printer is
that, to invoke the exception printer passed as last argument, the
procedure would have to pass a fallback printer to *that* printer, which
it can't do, as it doesn't know what that should be. Additionally, the
fallback printer has to be a closure anyway, as it needs access to the
`frame' argument passed to `print-exception' (see below).
>> 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).
>
> There are other cases that it would be nice to use it: in the catch-all
> in throw.c, and in general when printing exceptions from C.
>
I'll defer looking into that; I'll first make a follow-up patch dealing
with the call sites inside the REPL code.
>> 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.
>
> Let's keep the frame out of the exception-printer functions, but still
> pass it to the procedure that does the exception printing dispatch
> (perhaps called print-exception or something). That way we can print
> source information, then let exception printers do their thing.
>
The source info printing is now done only in the fallback printer, and
only on "regular match" exceptions (i.e. those that have the
conventional `args' structure). This is the same behavior as without
the patch. However, I think it would be more consistent to always print
source information if available; this would entail:
- Duplicating the source-information-printing logic of `display-error' in
`print-exception'.
- Always call `display-error' with #f as `frame', or perhaps stop
calling `display-error' and just print the exception ourselves.
What do you think?
>> [ 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. ]
>
> There are certainly some tangles here. If you find The Right Thing, let
> us know...
>
If we decide to do the source-information printing inside
`print-exception' (as proposed above), we might think about deprecating
`display-error' in favor of `print-exception'. Unfortunatly,
`display-error' cannot be implemented in terms of `print-exception', as
the former is missing the `key' argument that the latter requires.
Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>