I wonder whether we could collect the information on these parameters and nail down their interaction constraints somehow. (This could be a research project.)
On Mar 13, 2014, at 9:34 PM, Matthew Flatt 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