...not based on status code.
To simplify this logic, we now use the same error "type" both when
routes are not found and specific models are not found. One exception is
ours, one is from Laravel, but for the purposes of error handling they
should be treated the same.
Fixesflarum/core#1641.
...instead of status code. There are (or will be) multiple different
keys for similar errors with the same status code. In the future, we
will use the error's "type" (see flarum/core#1843) to distinguish them.
Refs flarum/core#1641.
The error handling middleware now expects an array of reporters.
Extensions can register new reporters in the container like this:
use Flarum\Foundation\ErrorHandling\Reporter;
$container->tag(NewReporter::class, Reporter::class);
Note that this is just an implementation detail and will be hidden
behind an extender.
This separates the error registry (mapping exception types to status
codes) from actual handling (the middleware) as well as error formatting
(Whoops, pretty error pages or JSON-API?) and reporting (log? Sentry?).
The components can be reused in different places (e.g. the API client
and the error handler middleware both need the registry to understand
all the exceptions Flarum knows how to handle), while still allowing to
change only the parts that need to change (the API stack always uses the
JSON-API formatter, and the forum stack switches between Whoops and
pretty error pages based on debug mode).
Finally, this paves the way for some planned features and extensibility:
- A console error handler can build on top of the registry.
- Extensions can register new exceptions and how to handle them.
- Extensions can change how we report exceptions (e.g. Sentry).
- We can build more pretty error pages, even different ones for
exceptions having the same status code.
This reverts commit 4abd6d61a9.
We will keep this fallback in place, to avoid unnecessary breakage of
backwards compatibility for extension authors.
Removal is planned for the final 0.1 release.
- Use existing `selectRaw()` method to avoid using the global `app()`
helper as a service locator, which hides dependencies.
- Do the same for the join.
- The `Expression` is necessary to prevent the aliased column from being
prefixed with the database table prefix, if configured.
