Re: [Chicken-users] 1095 (prerelease) + some eggs

[Joerg F. Wittenberger]

> >   (let loop ()
> >     (handle-exceptions
> >      ex (exception-handler ex)
> >      (receive
> >       (in-port out-port) (tcp-accept request-queue)
> >       (receive
> >        (local remote) (tcp-addresses in-port out-port)
> 
>                                                 ^
> `tcp-addresses' takes only a single argument. Normally, your
> exception-handler should logerr something. Are you compiling in
> safe mode?

Yes I do.  Apparently the execution doesn't reach the point.

How to I control the size of the stacktrace?  Except for the exception
handler I see only profiling calls and then the deadlock when
thread-join! is reached.

> >             (with-exception-handler
> >              ex (begin (close-output-port out-port) (loop)))))
> 
> Argh! Very wrong and very dangerous: the first arg to
> `with-exception-handler' must be the handler itself and the second

Horror.  Thanks.  What a shame.  Looks as if this wanted to become a
handle-exceptions, doesn't it?  I just try to avoid handle-exceptions
if the code allows me to do, because it saves a call/cc!  I'm not
claiming that my way is actually worth the risk of such mistakes.

> One question: SRFI-18 says that an uncaught exception is stored
> in the end-exception field of a thread and that the thread should
> terminate. If the parent now join!s,
> that uncaught exception will be raised. The problem is that errors
> in child-threads are not reported to the user, which makes debugging
> challenging, but not exactly fun.

As I understand, the exception is then raised in the context of the
joining thread, which in turn is responsible to handle (report) the
exception, isn't it?

> Should the default exception handler still invoke `error'? No,

affirm: the default exception handler must not invoke error, because
it no longer is.  Another, joining, thread might have a handler for
the exception.

> because that would throw back to toplevel (without storing something
> in the end- exception field).

right.

> So what should it do?
> 
> 1) Terminate silently, and store the end-exception

yes plus...

> 2) If not the primordial thread: Print a message to stderr and store it,
>     otherwise invoke `error'
> 3) something else

when the scheduler finds the last thread dying, print the result.  The
result is the end-exception field, if this is set, otherwise the value
of the thunk which was run in the thread.

/Jörg

-- 
The worst of harm may often result from the best of intentions.