>it's a tangential, but namely, when #:unwind #t then the handler in a w-e-h >returns from the w-e-h block, but with #:unwind #f it tries to return to the >RAISE that raised the condition. i.e. a lousy little keyword arg (usually a >page down) fundamentally changes the behavior of w-e-h. yet another surprise >that violated my expectations regarding APIs.
What is lousy and expectation-violating about a keyword argument doing what it name describes? If you have unwinded, it’s too late to return return from the raise (unless the implementation is doing delimited continuations shenanigans, which maybe you had in mind?), which explains the behaviour for #:unwind #true. If you are _not_ unwinding, then the handler can’t be run less deep in the call stack (i.e. “from the w-e-h block”), because to get less deep in the call stack, you need to unwind. So, there is a direct relation between unwinding/no unwinding, and returning from “the w-e-h block”/”raise(-continuable)”. If you don’t want Guile to unwind, then maybe don’t ask it to unwind. (Previous sentence N/A if you had above-mentioned delimited continuation shenanigans in mind.) That said, I would prefer it to be named something like [#:handler-context 'raise]/[#:handler-context 'guard] instead of #:unwind? #false/#true, since ‘unwind’ refers to the implementation instead of the semantics(*). That would reduce the need of roughly knowing how it is implemented (I have a rough idea for an alternate implementation where some unwinding always happens, and the handler is run in the dynamic environment of the ‘guard/with-exception-handler’ instead of the ‘raise’(*), and if raise-continuable is used and the handler returns something, then _re_winding happens via delimited continuations.). (*)I think this is how it’s supposed to work (?) (including in R6RS), but Guile doesn’t do this. (Except for interactions with dynamic-wind, which might now be incorrect in the case of raise-continuable, but really you shouldn’t be using dynamic-wind in the first place.) >anyway, i've attached a patch that clarifies what's happening for anyone who >stumbles upon this; i.e. be clearer that (?) a backtrace is printed due to >reaching a continuation barrier. Wait where did this happen? You say what’s happening, but you don’t seem to be referring to false-if-exception stuff, and you didn’t mention continuation barriers earlier. >if someone wants to investigate further, then i'm also attaching a new version >of my test.scm that behaves in an unexpected way on 3.0.9, but not on HEAD >(more specifically on guile-next in guix, which is a rather recent commit). It would be helpful to include in test.scm what the expected output would be and what unexpected output is encountered. Best regards, Maxime Devos.
