Feature #43569

Exception Handler should respect format

Added by Christopher Hlubek about 7 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Should have
Category:
Error
Target version:
-
Start date:
2012-12-04
Due date:
2013-04-13
% Done:

0%

PHP Version:
Has patch:
No
Complexity:

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

Related to Base Distribution - Work Package #45088: Improved REST support Resolved 2011-05-29 2013-04-13
Related to TYPO3.Flow - Feature #43247: Request respects format Closed 2012-11-23

History

#1 Updated by Bastian Waidelich about 7 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

#2 Updated by Bastian Waidelich about 7 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 almost 7 years ago

  • Parent task deleted (#45088)

#4 Updated by Aske Ertmann almost 7 years ago

  • Parent task set to #45088

#5 Updated by Bastian Waidelich almost 7 years ago

  • Due date set to 2013-04-06

#6 Updated by Bastian Waidelich almost 7 years ago

  • Due date changed from 2013-04-06 to 2013-04-13

#7 Updated by Bastian Waidelich almost 7 years ago

  • Parent task deleted (#45088)

#8 Updated by Bastian Waidelich almost 7 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 almost 6 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

#10 Updated by Christopher Hlubek almost 6 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.

#11 Updated by Bastian Waidelich almost 6 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

#12 Updated by Bastian Waidelich about 5 years ago

  • Status changed from Accepted to Closed

This ticket has been moved to https://jira.typo3.org/browse/NEOS-108

Also available in: Atom PDF