Re: small issue in get-multipart-header

On Thu, Feb 23 2006, Steve Haflich wrote:

>    From: Kamen TOMOV <[email protected]>
>    
>    Now that mention it, I wonder what is the proper way to find out
>    what kind of signals throws a particular black-boxed function
>    without studying its code?
>
> Well, only documentation and source reading can reveal what the code
> _might_ signal, but you can easily see what it actually does signal
> on any particular execution.  You can't do it with handler-case
> because when a handler-case clause is executed it has already thrown
> out of the protected code body.  (See the ANS pages for handler-case
> and handler-bind where is this explained pretty well).  But you can
> examine signals promiscuously using handler-bind, provided your
> handler(s) don't actually "handle" the signals by making a nonlocal
> exit.  Here's a minimal demonstration:
>
> cl-user(40): (handler-bind ((t #'describe)) (warn "Pie") pi)
> #<simple-warning @ #x1001f0e172> is an instance of #<standard-class simple-warning>:
>  The following slots have :instance allocation:
>   format-control     "~1@<Pie~:@>"
>   format-arguments   nil
>   plist              nil
> #<excl::advance-warning @ #x1000258f92> is an instance of #<standard-class excl::advance-warning>:
>  The following slots have :instance allocation:
>   format-control     <unbound>
>   format-arguments   nil
>   plist              nil
> Warning: Pie
> 3.141592653589793d0
> cl-user(41): 

That's a great idea. Thanks.

>    For example can I find out (with programming means) what kind of
>    signals this form (get-multipart-header req) can throw?
>
> You've missed the point entirely!  It is none of your business
> whether some body of code signals any conditions that are disjoint
> with the documented set of condition classes (error, warn, any
> implementration extensions) because they are the implementation's
> machinery.  In some fanciful implementation the cdr function might
> compute addresses using floating point arithmetic.  That's why you
> are not allowed to redefine or overload internal implementation
> functions.  Similarly, you are not allowed to mess with unexported
> condition classes.
>
> You have good reason for wanting to know the full set of subclasses
> of the cl:error condition, and perhaps also cl:warning.  (Some
> people might consider the required transitive specification of
> exceptions in Java code a positive feature of the language.  Or
> perhaps not, but it does seem to make Java programmers more
> sensitive to considering and classifying exceptions while we Lisp
> programmers seem to do it only as a casual afterthought.)  But if
> you need to know, or even think you need to know, about other
> condition classes that are disjoint from these, and not a documented
> part of siome subprogram interface, then something is wrong.

I guess I wasn't clear enough. Of course I understand that some
high-level form can signal various types of conditions, even strange
ones like if cdr uses floating point arithmetic :-) Therefore naturally
a matter of interest for me would be a small subset of them that
relate to the main functionality of the form.

> You may have noticed the excl::advance-warning condition signalled
> above.  The cl:warn in ACL first signals the normal warning, and if
> no one handles it (typically with muffle-warning) it signals an
> excl::advance-warning condition.  Programs like the file compiler
> use this to print those nice "While compiling function foo in file
> bar" messages without having to print functions that geenrate no
> warnings, and without the wasting stream real estate if multiple
> warnings occur within a single function.  There is a handler bind
> around the file compiler suppressing the "While compiling" message
> if the file and function are the same as the previous announcemen.
>
> The point of this condition class is that since it is disjoint from
> all documented condition classes except condition itself, no other
> code should ever notice it (because signal of an unhandled condition
> class is a nop) and certainly no other code should handle it.  There
> is no need to document that this machinery is being used by the
> compiler any more than it is necessary to document whether the
> compiler uses bit vectors.

Interesting. I wonder if this is part of the CL ANSI specification.

> As for get-multipart-header, it probably signals a variety of error
> subclasses.  Do you need to categorize them further?  For that you
> might need to read the code, and even so, specific errors signalled
> by routines called by that code could still be missed.  This is one
> aspect of Java that is arguably superior, although in practice most
> code just handles generic errors by transfering to some outer
> restart point.

In this particular situation I have decided to handle all the
conditions but to log them so that I would be able to investigate and
handle them in a particular way. It is because the time to read the
code is too limited.

Thank you very much.
-- 
Kamen TOMOV