Re: throw.c

[Marius Vollmer]

Dirk Herrmann <address@hidden> writes:


>   /* If we didn't find anything, print a message and abort the process
>      right here.  If you don't want this, establish a catch-all around
>      any code that might throw up. */
>   if (SCM_NULLP (winds) || SCM_FALSEP (dynpair))
>     {
>       scm_handle_by_message (NULL, key, args);
>       abort ();
>     }
> 
> Is it at all possible that dynpair is #f, or could this test be
> eliminated?

I think the test can be eliminated.

> Further, scm_handle_by_message never returns, which means we
> could get rid of the call to abort.

Yeees, but it makes me feel safer to have it in there, somehow.  Don't
know why.  It's probably just that I like defensive programming...

> Unfortunately, the name scm_handle_by_message doesn't indicate that
> the function will always terminate the application.  We should think
> of a better name.  Since the function is only used within throw.c
> and has the very special purpose to handle uncaught exceptions, we
> could make it static and call it, for example,
> handle_uncaught_and_exit.

It is part of the public API of libguile, and I sure someone out there
is using it together with scm_internal_catch. (Guile-gtk uses it, I
think.)  So we should be careful with such a change.  (I'm sure you
have considered this.)

Well, I'm unsure how to proceed.  Guile's condition system isn't too
clean to begin with, and I don't know whether we should bother to make
small changes to it that cause trouble for our users (because they
have more version dependencies to check for); or whether we should
just leave it as it is and rethink it in a larger way.  There is a
SFRI about this, right?  But I think it has been with-drawn.