[racket-dev] Changing the default error display handler to use

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Thu Mar 13 21:34:46 EDT 2014

At Wed, 12 Mar 2014 18:05:03 -0700, Eric Dobson wrote:
> A common issue I have is that the default error handler does not
> display error message's exn:srcloc if it has it [...]
> 
> Is this reasonable to add to the default error handler, and if so do
> people have suggestions on the format?

You mean the default error display handler, right?

I think this change may be worth a try, but there are many
exception-generating, exception-handling, and exception-printing
parameters to worry about, both in their interactions and how they're
currently used.

For example, does DrRacket use the default error display handler? If
so, it will start printing source locations that it's already showing a
different way, and I think that's not what you intend. Or some other
program harness might be worse off if the default display error handler
starts showing source locations. Then again, the whole point is that
you want to change the display of errors. Trying to change some things
and not changes others --- and having enough extension points to
accommodate certain combinations of changes and non-changes --- is why
the existing set of parameters and handlers is complex. I will not be
surprised if we end up with yet another parameter here.

If the change makes sense, probably the handler should not print the
first returned source location for `exn:fail:read`, `exn:fail:syntax`,
and `exn:fail:contract:variable` exceptions --- because that location
is supposed to be built into the error-message text, unless the
`error-print-source-location` parameter has a false value. Awkward, I
know; see the previous paragraph.

The right format is likely to print an extra "<field>: <detail>",
similar to the way that the default error display handler prints
context lines (if the `error-context-display-depth` parameter is not
0). I imagine that the source-location lines should precede the context
lines, but follow the exception's error message.


Posted on the dev mailing list.