Re: [Sbcl-devel] Misleading error message- implication is I called COMPILE-FILE when I didn't

[Pascal J. B. <pj...@in...>]

Douglas Katzman <do...@go...> writes:

> Pascal, I *get* all that.  The type of the condition object is what
> it is.
>
> I'm simply suggesting that one format statement could be better
> worded so as not to imply that it was a COMPILE-FILE operation.
> Here's the condition handler. I'm not sure enough information is
> propagated down to know that it was a LOAD-AS-SOURCE operation.
>
> (define-condition input-error-in-compile-file (reader-error
> encapsulated-condition)
> ...
>  (:report
>    (lambda (condition stream)
>     "~@<~S error during ~S: "
>    ...
>   'read
>   'compile-file   ;; <-- THIS is not the operation performed which
> led to a read error.

Permit me to insist.

When you call a function F, that function F may further call other
functions G, which may further call other functions H.

If an error is detected in H, what we have is a stack of frames, (F G
H), and this is the context of the error.  But the sanest thing to
report in the condition, if anything at all, is the function that
directly signaled the error, namely H.

Now, on the other hand, in the case of a library with "private" parts,
one could consider that the function to name in the condition should be
the public entry point.  And that may be what you're driving at:  the
public API you called was LOAD, and you'd consider COMPILE-FILE an
internal function.

That's what the discussion is about here.

In this case, the public API function LOAD called another public API
function, COMPILE-FILE, not an internal function.  And actually, the
function that really signaled that condition was probably an internal
sbcl function, an the condition protected us against it, indicating
COMPILE-FILE as the culprit.


Considering that we have access to the sources of the "library" or
implementation, as it's provided by the BACKTRACE, I'd say that it could
even report the internal function.

You're wanting to see only the function you called.  In my opinion, this
is a dangerous thing to ask for.  What if you actually called asdf:oos,
or ql:quicklisp?  Why not report those functions, instead of cl:load?
And who is "you"? Aren't all the functions called from _start(), main()
or SB-INT::TOP-LEVEL?

The "best" solution in my opinion would be to report a list of called
functions.  (Eg. I do that in the case of my RDP parser, reporting the
functions that correspond to grammar rules).  But I would think it would
be useful in general error reporting, even if it would reveal some
internal function names (this list of functions could be filtered by the
application in user reports, or by the user).

You would get something like:

     READ error during (SB-INT::TOPLEVEL SB-INT::REPL QL:QUICKLOAD
     QL-DIST::INTERNAL-LOAD ASDF:OOS ASDF::INTERNAL-LOAD-SYSTEM CL:LOAD
     CL:COMPILE-FILE SB-C::READ-FILE-FOR-COMPILATION CL:READ
     SB-INT::READ-OBJECT)


-- 
__Pascal Bourguignon__
http://www.informatimago.com/