Improve error handling

[tobyzerner]

Forum backend

• Load Whoops vs. a custom error handler middleware depending on whether debug config setting is on or off
• Design custom error pages - one for 404, one for 500
• Build said custom error handler to render appropriate said custom error page

API

• Load Whoops vs. a custom error handler middleware depending on whether debug config setting is on or off
• Build said custom error handler to output errors in JSON-API spec format

Forum frontend

• Design and handle error messages for empty sections (i.e. no discussion list results, no activity in a user's profile)
• Design and handle error page for discussion not found, user not found, route not found, etc.
• Better handling of general AJAX request errors (gracefully fail on unparseable JSON, timeouts, disconnect)
• Better handling of API errors (make sure all AJAX requests have an appropriate error handler, this would be handy)
• Nicer error message when the client fails to load due to a JS error

[franzliedke]

I've taken care of only enabling whoops in debug mode. I also built error handlers for the frontend and the API. The frontend error pages are rather plain - I'll let you work your design magic on them, @tobscure. Maybe you're also more creative than me in making them unique and fun.

One thing I'm not sure about right now is the following: for some errors like validation errors etc., we probably do not want to show Whoops, even when in debug mode, right? (I guess it depends on how AJAX errors are handled exactly in the frontend.) Any good idea how we could take care of those cases?

[tobyzerner]

Currently if the front-end doesn't receive JSON, it basically crashes the JS app. I will wrap the JSON parsing code with a try/catch so that it doesn't, and instead show a little red alert in the bottom left. So I think in debug mode any abnormal exception can trigger whoops and then you can use the browser inspector to see the error details.

But you're completely right about not wanting some errors (validation in particular) to be handled with whoops. We actually already have code in JsonApiAction@handle to catch some of those and output JSON-API spec errors. I think this could all be moved into a new error handler middleware. And if debug is not enabled, this needs to catch all exceptions and output a generic JSON-API spec error too.

Edit: the latter of which I see you've done! Nice!

[tobyzerner]

See #252 re: error pages

[tobyzerner]

What needs to be done:

• Backend first. In accordance with the JSON-API spec, we need to make sure we're returning the right error responses when things go wrong on the backend.
  • We should probably set up some base Exception classes that Actions/Commands can throw which will then be translated into the correct JSON-API response.
• Once that's good, we can tweak the front-end to handle these error responses in all instances.
  • Ideally we want a mechanism that allows callers of app.request to handle any error, but if they don't, it falls back to a default handler.

[franzliedke]

This should also be an exception, right? @tobscure

[tobyzerner]

@franzliedke yep.

[tobyzerner]

Closing this for beta 3. The rest is design stuff (polish) which isn't as high priority: #596

[franzliedke]

What about these three issues that were merged into this one?

• No error message when avatar uploading fails #165
• Flarum gets stuck when an edit is submitted after a subsequent reply is added #220
• Going to /u/userthatdoesnotexist just shows loading animated gif #552

At least the third one doesn't look like it's already fixed...

[tobyzerner]

True, will take a look at them tomorrow.

[tobyzerner]

#165 is fixed, #220 is fixed, and #552 will be tackled with #596.