[usocket-devel] Fwd: WITH-MAPPED-CONDITIONS and other WITH-* macros

[Erik Huelsmann]

On 3/26/08, Hans Huebner <hans.huebner at gmail.com> 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 <tcr at freebits.de>
> Date: 26.03.2008 13:55
> Subject: Re: WITH-MAPPED-CONDITIONS and other WITH-* macros
> To: Hans Hübner <hans.huebner at gmail.com>
>
>
> "Hans Hübner" <hans-zv1TXXZFLoBAfugRpC6u6w at public.gmane.org> 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
>