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."  Next worst is to display a raw error message which the user can only 
interpret by cutting and pasting it into a web search.  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.  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> 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+unsubscr...@googlegroups.com.
> 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.

Reply via email to