Hide boot error

[clarkwinkelmann]

Fixes #2290

Changes proposed in this pull request:

Completely redact boot error unless debug mode or display_errors is enabled. Attempt to use Flarum log file when possible.

Use HTTP error code 500 whenever a boot error occurs, whatever the handling method is.

Reviewers should focus on:

Screenshot

If debug mode is enabled, most errors will look exactly as before:

If debug mode is disabled, most errors including database and extension related will end up showing this:

If an error happened even earlier, which is unlikely, the error will appear in one of two ways (example: the file vendor/flarum/core/src/Foundation/Application.php is missing).

If display_errors is Off:

If display_errors is On:

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).

[clarkwinkelmann]

There's one thing you could give me input on: do you think the two special cases (debug mode and logger available) should be wrapped in a try/catch themselves? If the container is broken, app() could fail. There's also the possibility of an extension registering a binding to either of the abstracts resolved in this code, in which case the code could be faulty. This is very unlikely, but if this happens, there will be no way of accessing the original error.

flarum.config is probably safe, and I don't see why someone would bind an alias to LogReporter. I was considering manually instantiating LogReporter by passing the LoggerInterface so we know for sure our own code always runs here.

The remaining extensible aspect is if an extension binds to the LoggerInterface. But even if that happened, it would be very unlikely to have a boot error after that binding and also having the logger fail. If a custom logger fails, then the extension likely is very broken and wouldn't be fit for production.

[askvortsov1]

There's one thing you could give me input on: do you think the two special cases (debug mode and logger available) should be wrapped in a try/catch themselves? If the container is broken, app() could fail. There's also the possibility of an extension registering a binding to either of the abstracts resolved in this code, in which case the code could be faulty. This is very unlikely, but if this happens, there will be no way of accessing the original error.

As incredibly niche as this edge case is, I'm leaning towards handling it too, just so we don't need to worry about it ever again.

[clarkwinkelmann]

It does seem a bit overkill now, but at least everything should be covered.

I also moved the code into methods that more accurately describe what is ideal and what is fallback.

[askvortsov1]

This last line of the comment feels redundant given the contents of the echo above

[clarkwinkelmann]

Sure, I could remove it