URLs for site creating stack traces

[gavaletz]

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.

[drchoffnes]

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]

+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:
#25

[gavaletz]

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]

Ok, I'll make the changes described above.

[mdwelsh]

Any word on this?

[drchoffnes]

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//issues/25#issuecomment-8203102.

[mdwelsh]

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//issues/25#issuecomment-8247145.

[drchoffnes]

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//issues/25#issuecomment-8247830.