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
F19852695: D20137.diff
Fri, Mar 13, 3:50 AM
F19687759: D20137.diff
Feb 9 2026, 4:43 PM
F19681906: D20137.id48078.diff
Feb 8 2026, 11:02 PM
F19681887: D20137.id48078.diff
Feb 8 2026, 11:02 PM
F19102632: D20137.id.diff
Dec 5 2025, 7:07 AM
F19097768: D20137.diff
Dec 4 2025, 2:48 PM
F19051434: D20137.id48078.diff
Nov 28 2025, 1:07 AM
F19004837: D20137.id.diff
Nov 21 2025, 12:31 PM
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