On Mon, 06 Jan 2020 21:34:59 +0100 Andy Wingo <wi...@pobox.com> wrote: > On Mon 06 Jan 2020 00:26, Chris Vine <vine35792...@gmail.com> writes: > > I have a 'try' macro which adopts the approach that if an exception > > arises, the macro unwinds from the dynamic environment of the code > > where the exception arose to the dynamic environment of the call to > > 'try', evaluates the cond clauses in that environment, and then if no > > cond clause matches re-raises the exception in that environment with > > 'raise' (rather than 'raise-continuable'). In other words, it does > > stack unwinding in the same way as exception implementations in almost > > all other mainstream languages which use exceptions. It would be > > trivial to implement this with guile-3.0's with-exception-handler with > > its unwind? argument set to true. > > I am not sure this really matches with this use case: > > (define (call-with-backtrace thunk) > (call/ec > (lambda (ret) > (with-exception-handler > (lambda (exn) > (show-backtrace exn) ;; placeholder > (ret)) > thunk)))) > > (define (false-on-file-errors thunk) > (call/ec > (lambda (ret) > (with-exception-handler > (lambda (exn) > (if (file-error? exn) > (ret #f) > (raise-continuable exn))) > thunk)))) > > (define (foo f) > (call-with-backtrace > (lambda () > (false-on-file-errors f)))) > > > If there's an error while invoking `f' that's not a file error, you want > to have remained in the context of the error so you can show a full > backtrace. To my mind this is central to the exception handler design. > So far so good I think. > > If I change the implementation of `false-on-file-errors' to be: > > (define (false-on-file-errors thunk) > (guard (exn ((file-error? exn) #f)) > (thunk))) > > I think this change should preserve the not-unwinding environment that > `call-with-backtrace' expects.
Good point. My approach does provide the programmer with less conveyed stack information after the re-raise of an unhandled exception, requiring more manual intervention to recover the information when debugging the exception. Before you suggested it I had not previously considered your proposal. It may turn out to be the optimum solution, but I wonder if it would surprise the programmer to have the cond conditionals evaluated in a different dynamic environment from the one in which the cond consequential is evaluated where there is a conditional which is true. But I am not sure if that is of any importance. Chris