Andy Wingo <wi...@pobox.com> writes: > On Sat 27 Nov 2010 01:08, Andreas Rottmann <a.rottm...@gmx.at> writes: > >> to not lose current functionality, `print-exception' and exception >> printer procedures would need a `frame' argument as well, right? > > I guess. I never liked that, though; sounds like a needless tangling of > concerns. What does having the frame give us? Just source, or the > function name, or what? It seems like a message about the context in > which the error occurred could just as well come before the error is > printed out. > > What do you think? What does Ludovic think? :) > I share your sentiment that this is needless tangling, although I must admit I'm not at all familiar with the evolution and rationale for the design of `display-error'.
Fitting that you mention this issue, since I have a question that I think also touches this area: what to do with exceptions not caught by the REPL (i.e. those leading to program termination when running a script)? My previous patch did not touch them, but I think they should be changed as well, as a crash with "guile: uncaught throw to r6rs:exception: (#<r6rs:record:&raise-object-wrapper>)" is clearly suboptimal. However, besides the issue of how the error message should be formatted in this case (we probably need indenting for the R6RS condition representation, which is multi-line(?)), this also again raises the question of where `print-exception' should be defined, as the origin of this pre-termination error message is `default-exception-handler' in boot-9.scm. So, in my mind, this boils down to exactly define the interface of `print-exception', not only in terms of its argument list, but also in terms of the output it produces (multi-line? indented?). >>> For r6rs exceptions, I think either (rnrs conditions) or (rnrs >>> exceptions). >>> >> Ideally I'd like to put it into its own module. The exception printer >> should be able to freely use all of R6RS > > I understand the attraction of the "closure" aspects here > (R6RS-in-R6RS), but if you don't absolutely need higher levels of the > R6RS stack I would prefer for it to be implemented in (rnrs conditions) > or (rnrs exceptions), for the reason that you mention: > I think it should be managable; mainly, I just need access to `(rnrs records inspection)' and `(rnrs conditions)', so I think the latter would be an OK place to put the printer. >> `raise' and the condition system (for both the SRFI and R6RS >> varieties) are orthogonal, even if they are most often used together. > > I wasn't aware that this was the case for r6rs as well; > interesting. Well I suppose it's also possible for someone to throw > something unexpected to misc-error or to system-error. > >> A possible solution might be to allow an exception printer to decline >> to handle a specific raised object, and fall back on the default >> behavior. > >> exception-printer := port args -> boolean > > I like this suggestion; but I think the return value aspect is too > tricky. People will end up relying on the return value of whatever the > last function in the printer is, and that could be unspecified, and > indeed "unspecified values"... better to be explicit. > Yes, that's indeed a common mistake, at least in my experience. > So instead, how about > > exception-printer: port args exception-printer > > Does that make sense at all? If the given printer doesn't like the args, > it calls the default printer given to it as an arg. > Yeah, that makes sense to me. I suggest calling the parameter `punt' and recommend it being called in tail position (if at all), to facilitate the same potential looping behavior we'd get with a boolean return value, if that makes sense to you. > Anyway, so much API noodling over a small thing; but I do think it will > make Guile hacking better. > Yep, it's a needed addition, I agree. Cheers, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
