TYPO3.Flow

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?

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 ;)

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

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.

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