Feature #43569
Exception Handler should respect format
0%
Description
The DebugExceptionHandler and ProductionExceptionHandler do not respect other formats than HTML in a meaningful way.
It should be possible to get syntactically correct exception / error messages in the most common formats (JSON, XML).
Related issues
Updated by Bastian Waidelich about 8 years ago
- Category set to Error
- Status changed from New to Accepted
- Assignee set to Bastian Waidelich
- Parent task set to #45088
I have a basic prototype working and will try to fix this with #45088
Updated by Bastian Waidelich about 8 years ago
Bastian Waidelich wrote:
I have a basic prototype working and will try to fix this with #45088
FYI: The current implementation fetches the current request (via RequestHandler->getRequest()) and checks it's format and/or Accept headers to determine a matching rendering format. This does not work on CLI therefore the default should probably be "plaintext".
Do have ideas/resources on how to format exceptions in JSON/XML for best compatibility?
Updated by Bastian Waidelich almost 8 years ago
I'm still on this one, but I won't make it within the timeframe of #45088 (which is already over).
If anyone comes up with a good architecture for rendering exceptions according to the Accept header, please share ;)
Updated by Bastian Waidelich almost 7 years ago
I still couldn't find a good hypermedia format for errors.. Maybe we could use application/api-problem+json but that was meant to be used for APIs and there is not XML counterpart it seems.
But probably a simple standard json/xml like
{ "errors":[ { "message": "Foo Bar", "code":1234 } ] }
would already be much better than the html stacktrace that is currently rendered by default.
See https://www.mnot.net/blog/2013/05/15/http_problem for some more details
Updated by Christopher Hlubek almost 7 years ago
Bastian Waidelich wrote:
I still couldn't find a good hypermedia format for errors.. Maybe we could use application/api-problem+json but that was meant to be used for APIs and there is not XML counterpart it seems.
But probably a simple standard json/xml like
[...]would already be much better than the html stacktrace that is currently rendered by default.
See https://www.mnot.net/blog/2013/05/15/http_problem for some more details
Just briefly skipped through the blog article. Regarding the new media type: It makes sense, but for Flow it's too generic because a developer needs to create those URLs for problems and problem instance linking. Also the multiple errors feature is missing, but we handle only a single exception anyway, right? (Except for the planned multi-dispatch HTTP service for Neos)
So I'm in favor of a simple solution, but we should include the reference code to find the logged exception later.
Updated by Bastian Waidelich almost 7 years ago
Christopher Hlubek wrote:
Regarding the new media type: It makes sense, but for Flow it's too generic because a developer needs to create those URLs for problems and problem instance linking.
As far as I understand most of the properties are optional. The type is expected to be an URI, not necessarily an URL. So it could be s.th. like http://typo3.org/flow/exception-types/<the-type>.
The instance could be the unique exception code we generate.
Also the multiple errors feature is missing, but we handle only a single exception anyway, right?
(Except for the planned multi-dispatch HTTP service for Neos)
True
So I'm in favor of a simple solution, but we should include the reference code to find the logged exception later.
+1
Updated by Bastian Waidelich about 6 years ago
- Status changed from Accepted to Closed
This ticket has been moved to https://jira.typo3.org/browse/NEOS-108