Yes the default error display handler.

Ok, I'll put this on my list of things to do, and hopefully have a
version for review at some point.

On Thu, Mar 13, 2014 at 7:22 PM, Robby Findler <ro...@racket-lang.org> wrote:
> You'll want to check DrRacket in both "Debugging" and "No Debugging and
> Profiling" mode to see if you're happy with the results (and I can help
> change them if you're not happy with them).
>
> Robby
>
>
> On Thu, Mar 13, 2014 at 8:34 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
>>
>> 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.
>>
>> _________________________
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>
>
_________________________
  Racket Developers list:
  http://lists.racket-lang.org/dev

Reply via email to