guile-devel
[Top][All Lists]
Advanced

[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/>



reply via email to

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