Open gavaletz opened 12 years ago
drchoffnes
commented
12 years ago SGTM. I think we can refactor such that
1) stack traces are dumped to the error log 2) browsers are redirected to a generic error page with a description of the error and, as you say, links to something like a FAQ.
Another thing we can do is print the stack trace to the response if the user is logged in as a developer/admin user.
Any other suggestions/thoughts?
mdwelsh
commented
12 years ago +1 - this is a pretty ugly UX at the moment.
On Mon, Apr 16, 2012 at 10:23 AM, gavaletz reply@reply.github.com wrote:
This is something that is unlikely to happen from average users, but IMO it poses two issues when it does happen:
1) You are exposing implementation (not a huge thing since MobiPerf is open source). 2) It looks sloppy and does not help the user do the right thing.
If I were to enter a URL such as http://openmobiledata.appspot.com/checkin
It should do something other than dump a stack trace to my browser. In most cases it should redirect to a help or FAQ instructing them about how to use the site.
In my case I was looking for JSON serialized data with the link '/timeseries/data'. Note that I am not saying that for development we shouldn't display the stack trace, but we should have a plan to do something more friendly for users.
Reply to this email directly or view it on GitHub: https://github.com/Mobiperf/MobiPerf/issues/25
gavaletz
commented
12 years ago We can/should anticipate a lot of the things that would have caused stack traces and catch them sooner. I do think that Dave has the right idea though about a last ditch effort to catch unexpected errors, and it would be a good version 1 solution too.
drchoffnes
commented
12 years ago Ok, I'll make the changes described above.
mdwelsh
commented
12 years ago Any word on this?
drchoffnes
commented
12 years ago The original server code has a line:
application = wsgi.WSGIApplication(m, debug=True)
The stack trace goes away and instead an HTTP 500 response is sent when debug=False. This is the immediate fix.
The longer-term fix is that each request handler has to define a nice way to deal with errors that isn't a generic exception.
Should I submit the short-term fix or wait until I've defined a handler for all the code that doesn't gracefully handle exceptions?
On Fri, Aug 31, 2012 at 12:50 PM, Matt Welsh notifications@github.comwrote:
Any word on this?
— Reply to this email directly or view it on GitHubhttps://github.com/Mobiperf/MobiPerf/issues/25#issuecomment-8203102.
mdwelsh
commented
12 years ago I'd say short term fix for now.
Thanks!
On Mon, Sep 3, 2012 at 2:12 PM, drchoffnes notifications@github.com wrote:
The original server code has a line:
application = wsgi.WSGIApplication(m, debug=True)
The stack trace goes away and instead an HTTP 500 response is sent when debug=False. This is the immediate fix.
The longer-term fix is that each request handler has to define a nice way to deal with errors that isn't a generic exception.
Should I submit the short-term fix or wait until I've defined a handler for all the code that doesn't gracefully handle exceptions?
On Fri, Aug 31, 2012 at 12:50 PM, Matt Welsh notifications@github.comwrote:
Any word on this?
— Reply to this email directly or view it on GitHub< https://github.com/Mobiperf/MobiPerf/issues/25#issuecomment-8203102>.
— Reply to this email directly or view it on GitHubhttps://github.com/Mobiperf/MobiPerf/issues/25#issuecomment-8247145.
drchoffnes
commented
12 years ago Submitted in issue 9001.
On Mon, Sep 3, 2012 at 2:56 PM, Matt Welsh notifications@github.com wrote:
I'd say short term fix for now.
Thanks!
On Mon, Sep 3, 2012 at 2:12 PM, drchoffnes notifications@github.com wrote:
The original server code has a line:
application = wsgi.WSGIApplication(m, debug=True)
The stack trace goes away and instead an HTTP 500 response is sent when debug=False. This is the immediate fix.
The longer-term fix is that each request handler has to define a nice way to deal with errors that isn't a generic exception.
Should I submit the short-term fix or wait until I've defined a handler for all the code that doesn't gracefully handle exceptions?
On Fri, Aug 31, 2012 at 12:50 PM, Matt Welsh notifications@github.comwrote:
Any word on this?
— Reply to this email directly or view it on GitHub< https://github.com/Mobiperf/MobiPerf/issues/25#issuecomment-8203102>.
— Reply to this email directly or view it on GitHub< https://github.com/Mobiperf/MobiPerf/issues/25#issuecomment-8247145>.
— Reply to this email directly or view it on GitHubhttps://github.com/Mobiperf/MobiPerf/issues/25#issuecomment-8247830.
This is something that is unlikely to happen from average users, but IMO it poses two issues when it does happen:
1) You are exposing implementation (not a huge thing since MobiPerf is open source). 2) It looks sloppy and does not help the user do the right thing.
If I were to enter a URL such as http://openmobiledata.appspot.com/checkin
It should do something other than dump a stack trace to my browser. In most cases it should redirect to a help or FAQ instructing them about how to use the site.
In my case I was looking for JSON serialized data with the link '/timeseries/data'. Note that I am not saying that for development we shouldn't display the stack trace, but we should have a plan to do something more friendly for users.