Re: Dynamic loading progress

[Davis Herring]

> So what's the advantage over unwind_to_catch as implemented?  You
> still need to put the barrier in place, only now you're using mixed
> idioms (Lisp for the pitcher, C++ for the catcher).  That kind of
> thing always gives me hives.

As I think I said, it lets you avoid reinstalling the handler every time
you call into Emacs (and thus having to wrap every Emacs API function).

>  > But it's not ignore-errors: in my example,
> 
> A-ah, that's *your* example.  I was referring to what I believe Daniel
> and Philipp want, which was the idea you pretty much dismissed as
> "[too] inflexible": a handler hidden behind the API.

(I'm still talking about my example here, but only because it serves to
demonstrate what properties a hidden handler might have.  Another
implementation of hidden handlers could of course behave differently,
but I haven't seen any particular implementation firmly chosen.)

Even if the handler is hidden, the signal isn't swallowed (or even
turned into a famously-easy-to-ignore return code): it's turned into an
exception and thrown.  It's up to the module code what to do about it,
as always.  My follow-on template-wrapper idea didn't squelch exceptions
either, but turned them back into propagating Lisp signals after having
run whatever C++ destructors.

The inflexible part of the automatic/hidden handler, as I saw it, is
that every entry point must perform the try/catch even if it has no
destructors to run because Emacs will cause the exception to be thrown
anytime control is within the module.  It also prevents doing any
preparatory work before installing the handler, or making a dynamic
choice of handler -- but for neither of those do I have a use case at
the moment.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.