Feature #43569
Exception Handler should respect format
Status: | Closed | Start date: | 2012-12-04 | |
---|---|---|---|---|
Priority: | Should have | Due date: | 2013-04-13 | |
Assigned To: | Bastian Waidelich | % Done: | 0% |
|
Category: | Error | |||
Target version: | - | |||
PHP Version: | Complexity: | |||
Has patch: | No |
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
History
#1 Updated by Bastian Waidelich over 2 years ago
- Category set to Error
- Status changed from New to Accepted
- Assigned To set to Bastian Waidelich
- Parent task set to #45088
I have a basic prototype working and will try to fix this with #45088
#2 Updated by Bastian Waidelich over 2 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?
#3 Updated by Aske Ertmann over 2 years ago
- Parent task deleted (
#45088)
#4 Updated by Aske Ertmann over 2 years ago
- Parent task set to #45088
#5 Updated by Bastian Waidelich over 2 years ago
- Due date set to 2013-04-06
#6 Updated by Bastian Waidelich over 2 years ago
- Due date changed from 2013-04-06 to 2013-04-13
#7 Updated by Bastian Waidelich over 2 years ago
- Parent task deleted (
#45088)
#8 Updated by Bastian Waidelich over 2 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 ;)
#9 Updated by Bastian Waidelich about 1 year 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
1{ 2 "errors":[ 3 { 4 "message": "Foo Bar", 5 "code":1234 6 } 7 ] 8}
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
#10 Updated by Christopher Hlubek about 1 year 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.
#11 Updated by Bastian Waidelich about 1 year 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
#12 Updated by Bastian Waidelich 8 months ago
- Status changed from Accepted to Closed
This ticket has been moved to https://jira.typo3.org/browse/NEOS-108