Re: [racket-dev] Changing the default error display handler to use
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
Re: [racket-dev] Changing the default error display handler to use
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
Re: [racket-dev] Changing the default error display handler to use
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
Re: [racket-dev] Changing the default error display handler to use
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
[racket-dev] Changing the default error display handler to use exn:srclocs
A common issue I have is that the default error handler does not display error message's exn:srcloc if it has it racket -e (require racket/match) -e (match 2) = match: no matching clause for 2 context...: /Users/endobson/proj/rnacket/plt/racket/collects/racket/match/runtime.rkt:21:0: match:error But no information about what match raised the issue. The handler in DrRacket uses this info nicely in the buttons that it provides and the highlighting. Is this reasonable to add to the default error handler, and if so do people have suggestions on the format? My current .racketrc has (let ((old-error-display-handler (error-display-handler))) (error-display-handler (λ (str exn) (when (exn:srclocs? exn) (for ((srcloc ((exn:srclocs-accessor exn) exn))) (displayln (source-location-string srcloc (old-error-display-handler str exn) Which is a hack but works for my interactive use. It doesn't work for when I run a program on its own, and I don't see a way to configure anything to do that. _ Racket Developers list: http://lists.racket-lang.org/dev
