On Saturday, March 23, 2019 at 5:17:22 AM UTC+8, James Platt wrote:
>
> Well, I might make some kind of compromise. What I don't want to allow is
> the possibility of the user experience being "I click on the button and
> nothing happens."
You can wrap each button callback with a `with-handlers` call that displays
a message box when an exception is raised inside the callback, but this
user interface might not be very pleasant to use. Also this will not help
you if your callback does something like:
(when #f
;; rest of the code here
)
> Next worst is to display a raw error message which the user can only
> interpret by cutting and pasting it into a web search.
If the user can do nothing about this error except report it back to the
developer, you can just log this error to a file, display an "Internal
Error" dialog box and instruct the user to add the log file to their bug
report.
> So yes, I could just get that far and then try and fix all the bugs rather
> than try and handle every possible exception gracefully.
If you have a limited amount of time available, I would suggest you spend a
little of that time on code that displays "Internal Error" and most of that
time in detecting and fixing these bugs. You won't be able to fix all of
them, but you can go a long way of making the "Internal Error" dialog box
be a rare occurrence in your application.
You should display more information to the user, only if the user can
actually do something to fix the problem (e.g if you cannot open a file,
tell the user which file you cannot open), otherwise your application
should just log the exception into a file, along with other debugging
information so you can reproduce the problem, than instruct the user to
report a bug and attach the log file.
> More likely, meet somewhere in the middle of those approaches.
>
>
> On Mar 22, 2019, at 4:55 PM, Robby Findler wrote:
>
> > I know this will sound silly, but you could just consider them bugs and
> the fix them? (I went through a similar thought process with DrRacket years
> ago and that was the conclusion I came to-- just slap an "internal error"
> message on it so people aren't confused about it being a bug in their
> program.)
> >
> > Robby
> >
> > On Fri, Mar 22, 2019 at 3:09 PM James Platt <j...@biomantica.com
> <javascript:>> wrote:
> > I'm working on displaying informative error messages in a GUI and I have
> been finding that many of the things I need to handle are contract
> violations in downstream functions. The thing is that it seems like there
> ought to be a better way than the methods I can think of.
> >
> > It's very simple to use the predicate exn:fail:contract? to tell if
> there was a contract violation but this doesn't tell me which downstream
> function or which parameter caused the error. I could parse the full error
> message with regular expressions and use that to build my error message for
> the user. However, this turns out to be a lot of code and it also seems
> like it could break down if a future update to Racket or some package
> changes the wording of an error message. I could go to the downstream
> functions, remove their contracts and, instead, have them raise custom
> exceptions. Then catch those exceptions in the GUI code. Not only is this
> a lot of code to change but it seems wrong to start with code created
> according to good practice and then undo it for further improvement.
> >
> > So my question is whether there is a better way to do this than I am
> aware of?
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users...@googlegroups.com <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
