Hi, Josselin Poiret <d...@jpoiret.xyz> skribis:
> We also use a big wrapping `with-error-handling` to display errors > properly in the case when they are not caught. The difference is that > `with-error-handling` adds a non-unwinding handler, while catch is > unwinding. My first thought was that non-unwinding handlers, even outer > ones would get priority over unwinding ones, since once the stack's > unwound you can't really go back (I have no idea if that last part is > actually true). In practice this is actually false, I tested with a > very simple example, but that lead me to test by setting `#:unwind? #t` > for the `guard*` definition in guix/ui.scm and the issue went away, so I'm > clueless as to why this happens. What seems weird is that the error is > not caught at all! Here’s a reproducer: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> (with-exception-handler (lambda _ (catch 'x (lambda () (throw 'x)) (const 'good) )) (lambda () (rmdir "/")) #:unwind? #f) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `x' with args `()'. --8<---------------cut here---------------end--------------->8--- Or, simplified: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> (with-exception-handler (lambda _ (with-exception-handler (const 'good) (lambda () (throw 'x)) #:unwind? #t)) (lambda () (rmdir "/")) #:unwind? #f) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `x' with args `()'. --8<---------------cut here---------------end--------------->8--- We expect 'x to be caught, leading the handler to return 'good. Instead, 'x is not caught at all. In both cases, setting #:unwind? #t in the outer ‘with-exception-handler’ gives the expected result. I spent some time staring at the relevant code in ‘boot-9.scm’ but nothing came out of it. Ludo’.