Re: (warn) isn't doing what I expect it to

Kent M Pitman wrote: 
Nathan Baum <nathan_baum@xxxxxxxxxxxxxx> writes:


Edi Weitz wrote:

On Mon, 29 Aug 2005 23:13:44 +0100, Nathan Baum <nathan_baum@xxxxxxxxxxxxxx> wrote:


So HANDLER-CASE unwinds the dynamic environments before executing
its forms. Most unexpected. It works if I use HANDLER-BIND.


Why unexpected?  That exactly is the difference between HANDLER-CASE
and HANDLER-BIND.

But I didn't expect that to be the difference. ;) 

Because you read that the effect would be otherwise in some authoritative
place that was wrong?  Or because you just made up an effect that you hoped
it would happen and wishing didn't make it so?  Or because you mis-read what
someone else had written?  I'm always curious what the source of radical
misconceptions is, and especially so in this case since it's an area about
which there is rampant confusion.  I'm not trying to embarrass  you--this
is just random statistics-taking on my part.  Feel free to reply in private
mail if you'd like.

The closest option you presented was "I just made up an effect that you hoped it would happen and wishing didn't make it so."

But it does rather misrepresent things. I didn't just "make up" an effect. I expected it to have the same effect as HANDER-BIND except for the differences that I already knew it had: its syntax, and inhibiting further propogation of the signal.

I didn't expect it to unwind the dynamic state before evaluating the handler, because I thought I had already fully grokked the distinction.

Assuming there is a MISSING-FUNCTION warning that is a subclass of
WARNING (and there is none such defined by CL), you should be able
to do:

 (handler-bind (((and warning (not missing-function))
                #'muffle-warning))
   (do-something))

That is, rather than explicitly force output for something that was
going to output anyway, just head off the output for things you don't
want output about...

As I made clear, I _don't_ want the implementation dependent warning output. MISSING-FUNCTION is domain-specific condition which I wish to display and otherwise respond to in a domain-specific manner.

I want warnings 'from Lisp' to pass through as normal. (Of course the cost I originally posted didn't do that, but that was just a simplification to illustrate the problem I was having.)

The idea of writing something to do FORMAT such as you suggest is
wrong for several reasons.

 - You're outputing to *STANDARD-OUTPUT*, which is not where
   warnings are ordinarily meant to go--it gets them mixed up
   in output for programs.

Not a problem for this instance. The program is an interactive evaluator for a non-Lispy language, and I _want_ the warnings to be mixed up in output. On the other hand, I want warnings 'from Lisp' to go elsewhere, possibly a log.

 - You're printing the word "WARNING" onto the stream rather than
   leaving it to the system to use the appropriate notation for the
   particular implementation.


As noted above, the implementation dependent notation isn't appropriate.

 - You're bypassing the system's natural desire to end your warning
   text with a newline.  You're not required to put a newline into
   a warning or error message, but the system is supposed to supply
   one.

In the real code, the newline is provided elsewhere. It turned out that way because CLISP doesn't put a newline after a warning:

  (progn (warn "foo")
         (princ "bar"))

I don't feel the need to change things, since putting a newline in there messes up the display, and removing it from where it is displayed at the moment means that normal Lisp warnings (which I'm not yet redirecting to a log) will be messed up when using CLISP.

 - You're printing the error message with ~A about the name of a
   function, hiding appropriate escaping that should be done.
   That is, if the function's name is |FOO\\xyz| you're going to
   output FOO\xyz which will confuse people about whether the \
   is part of the name or just an escape for the x that follows.
   If you use ~S instead, the name will output as FOO\\\x\y\z or
   |FOO\\xyz| or FOO\\|xyz| any of which may look ugly, but are
   parseable by Lisp.

The function in question isn't a Lisp function, and doesn't follow Lisp's rules for symbol syntax. The accessor should probably be MISSING-FUNCTION-NAME, since it's a string (at the moment, I haven't made these conditions; I'm just using simple conditions).

The function named "|FOO\\xyz|" would genuinely be named "|FOO\\xyz|".

 - You're writing code that does (format ...) in order to keep code
   from executing that intends to do (format ...), which is just
   repeated effort.

I'm writing code that does (format <known arguments>) in order to keep code from executing that indends to do (format <implementation dependent arguments>).

 http://www.nhplace.com/kent/Papers/Exceptional-Situations-1990.html
 http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html
[These two papers cover different issues, so it's worth reading both.]


Good stuff, thanks.
.

Relevant Pages

  • Re: call-next-method weirdness
    ... Lisp: the warnings/errors generally indicate precisely what has gone wrong. ... when debugging in other languages when, ... error message turned out to have actually described ... Like meaningful warnings. ...
    (comp.lang.lisp)
  • Re: readdir formulated badly? gives wrong count
    ... It won't print a newline, ... Yeah your right... ... where that is not a good place for warnings. ...
    (perl.beginners)
  • Re: blocks world
    ... i attempt to make the blocks world from winston and horn, lisp. ... i still get these warnings: ... The following special variables were not defined: ...
    (comp.lang.lisp)
  • Re: checkpatch.pl and no newline handling
    ... newline, yet rejects patches that fix newlines in files ... ... opposite of what we actually want ... 0 errors, 1 warnings, 1 lines checked ... apw@pinky$ echo "moo">newline.c ...
    (Linux-Kernel)
  • Re: Reading lines from a file
    ... You mean each record ends with 4 equal signs and a newline? ... use warnings; ... use strict; ...
    (comp.lang.perl.misc)