Andy Wingo <wi...@pobox.com> 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 <a.rottm...@gmx.at> 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/>
