On 3/26/08, Hans Huebner <[EMAIL PROTECTED]> wrote:
> Here is an email I received from Tobias in response to my suggestion
> to wrap the body of invocations of WITH-CONNECTED-SOCKET with a
> WITH-MAPPED-CONDITIONS. We discussed his comment afterwards and came
> to the conclusion that it will be problematic to get nested occurences
> of WITH-CONNECTED-SOCKET to work if the all of the handlers for any of
> the involved conditions declines. For conditions signalled with ERROR
> (which is what usocket needs to do anyway) this will be no problem, as
> ERROR itself will invoke the debugger if all handlers decline. With
> SIGNAL, the behavior Tobias describes could be observed, which would
> clearly be unwanted.
Well, Tobias indicates absense of RESIGNAL or DECLINE, but when a
handler returns from a SIGNALled condition, in handler-bind, that's
considered a DECLINE.
If you want to make an explicit RESIGNAL, you can simply take the 'w'
parameter to the handler function and (SIGNAL w) again. Note that
that's a new invocation of SIGNAL, which in itself can return. If you
decide to handle a returning SIGNAL by returning yourself from the
handler function, that's also considered a DECLINE. In the case of
SIGNAL, that means the SIGNAL statement will return NIL and continue
execution.
Does that not allow you to do what you want to do? I mean... you can
get a single printed line in the output below by just returning from
your handler (removing the SIGNAL statement).
Does that explain the condition system a bit?
HTH,
Erik.
> ---------- Forwarded message ----------
> From: Tobias C. Rittweiler <[EMAIL PROTECTED]>
> Date: 26.03.2008 13:55
> Subject: Re: WITH-MAPPED-CONDITIONS and other WITH-* macros
> To: Hans Hübner <[EMAIL PROTECTED]>
>
>
> "Hans Hübner" <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > how would you feel about adding a WITH-MAPPED-CONDITIONS to the
> > expansion of WITH-CONNECTED-SOCKET? The reason for that is that it is
> > possible that stream read/write operations on a socket stream generate
> > socket errors that need conversion.
> >
> > Thoughts?
>
>
> I'm not familiar with the usocket source base, but I found out yesterday
> the hard way that remapping conditions that work properly when being
> nested is entirely not trivial.
>
> CL-USER> (handler-bind ((warning #'(lambda (w)
> (format t "<1> ~S~%" w)
> (signal w))))
> (handler-bind ((warning #'(lambda (w)
> (format t "<2> ~S~%" w)
> (signal (make-condition 'warning)))))
> (warn "FOO")))
>
> <2> #<SIMPLE-WARNING {B7060A1}> ; created by the (warn "FOO")
> <1> #<WARNING {B706CE1}> ; created by the (make-condition 'warning)
> <1> #<SIMPLE-WARNING {B7060A1}> ; same as in <2> <-- WE DON'T WANT
> THIS TO HAPPEN
> WARNING: FOO
> NIL
>
> The problem is that handler <2> signals the conditions _anew_, but if
> this newly signalled condition isn't handled anywhere upwards, the
> condition that was originally signalled continues its search for a
> handler further upwards (causing handler <1> to be run twice.)
>
> The problem is that there's no RESIGNAL operator (or a DECLINE) operator
> in Common Lisp, making this really troublesome.
>
>
> My point is that: If WITH-CONNECTED-SOCKET is supposed to work when
> being nested (or if multiple WITH-MAPPED-CONDITIONS can appear in the
> extent of a WITH-CONNECTED-SOCKET), you have to be careful not to screw
> up.
>
> HTH,
>
> -T.
>
>
> --
> Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht
> und ist - aktuelle Virenscanner vorausgesetzt - sauber.
> Freebits E-Mail Virus Scanner
> _______________________________________________
> usocket-devel mailing list
> usocket-devel@common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
>
_______________________________________________
usocket-devel mailing list
usocket-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
