Page MenuHomePhabricator

Try harder to present display/rendering exceptions to the user using standard exception handling
ClosedPublic

Authored by epriestley on Feb 11 2019, 5:38 PM.
Tags
None
Referenced Files
F13293462: D20137.id48078.diff
Wed, Jun 5, 7:51 AM
F13290676: D20137.id48095.diff
Tue, Jun 4, 7:41 PM
F13287021: D20137.diff
Tue, Jun 4, 8:08 AM
F13274124: D20137.diff
Fri, May 31, 3:18 AM
F13260525: D20137.diff
Mon, May 27, 12:01 AM
F13217656: D20137.id.diff
Sat, May 18, 6:53 AM
F13215271: D20137.id48078.diff
Fri, May 17, 4:14 PM
F13210490: D20137.diff
Fri, May 17, 4:54 AM
Subscribers
None

Details

Summary

Ref T13250. When exceptions occur in display/rendering/writing, they currently go straight to the fallback handler. This is a minimal handler which doesn't show a stack trace or include any debugging details.

In some cases, we have to do this: some of these exceptions prevent us from building a normal page. For example, if the menu bar has a hard fatal in it, we aren't going to be able to build a nice exception page with a menu bar no matter how hard we try.

However, in many cases the error is mundane: something detected something invalid and raised an exception during rendering. In these cases there's no problem with the page chrome or the rendering pathway itself, just with rendering the page data.

When we get a rendering/response exception, try a second time to build a nice normal exception page. This will often work. If it doesn't work, fall back as before.

Test Plan

Screen Shot 2019-02-11 at 9.32.42 AM.png (1×2 px, 236 KB)

  • After:

Screen Shot 2019-02-11 at 9.36.53 AM.png (1×2 px, 520 KB)

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable