> >do i get this right? (with-exception-handler ... #:unwind? #f) installs a so > >called pre-unwind-handler, which takes priority over a false-if-exception, > >even if deeper in the stack, because f-i-e installs a post-unwind-handler? > > It’s not post-unwind? If anything, I would call it pre-unwind. If > with-exception-handler were post all the unwinding, then it’s too late to let > raise-continuable return anything.
i didn't properly understand the meaning of pre-unwind and post-unwind handlers when i wrote the above. i thought they are something more peculiar than what they actually are. > But other than that (“[it] takes priority over a false-if-exception, [...]), > that’s my understanding of things. > > I guess what should be done, is it _not_ having priority, and instead it only > handling things when there noguard/catch/... inside has caught the exception. what i didn't understand is that FALSE-IF-EXCEPTION is implemented with a simple CATCH, so its handler should have shadowed my handler. but what actually happens is more sinister, see my other mail with the test case. > Going by < 9.1 Condition System Concepts | Common Lisp (New) Language > Reference (lisp-docs.github.io)>, the API and semantics of CL is pretty much > the same as guard/with-exception-handler/raise(-continuable) stuff(*). yep. with the addendum that CL has two entirely different macros for unwinding and non-unwinding WITH-EXCEPTION-HANDLER. and the handlers are always uninstalled before they are called. and there's no multitude of duplicate primitives for almost identical functionality due to a single revision of the CL standard. > (I haven’t found search results on what backtrace decorators are in CL.) this is user code, sorry. it's something we added to be able to decorate backtraces with domain-specific data. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- <hcf> information we gather and create overflows our means of managing it <hcf> our ppl r only happenstancely synergistic
