404 handling

[WanWizard]

Dedicated 404 route plus internal 404 handling if the special route is not defined. Dedicated 404 exception?

[WanWizard]

@stevewest This can also be handled as part of the decoupling, as the response status is related to response rendering.

[emlynwest]

Ok, sounds like I need to get on with that task then 😉

[sagikazarmark]

Dedicated HTTP exception? 403 also sounds like a valid target for a custom page. BTW do we need an actual route for this? Isn't a special template enough? #simplicity

This could go into an error controller/listener:
If there is an error404.template use it
(If there is an error4xx.template use it)
If there is an error.template use it

User can override the builtin error controller/listener

[emlynwest]

Sounds good to me, I'm all for simple.

[WanWizard]

The problem with an exception is that you are pulled out the the normal execution flow. This has in v1 also read to a problematic solution in the index.php with the result that you lose all context of the original request.

@sagikazarmark your suggestion suggests a (fixed) HTML response, which I don't think is a good idea.

If we go for exceptions, I think we need to capture them all (= "system exceptions") at the point the controller is invoked, so we can replace the Response from the controller by a new Response related to the exception captured. That response can than be injected into the normal flow, and rendered bsaed on the required response format (which could be something else than HTML).

[sagikazarmark]

@sagikazarmark your suggestion suggests a (fixed) HTML response, which I don't think is a good idea.

Care to elaborate? Because in the following paragraph you basically explained how I also imagined error handling to work under the hood and I don't see a contradiction. My point was that for the user it might be enough (on high level) to just put some HTML in a template (following the above fallback chain: 404->4xx->error) and we handle the rest. Of course the user should be able to hook into this logic (which renders the error response), but in most of the cases it sounds just enough to me.

I remember that we imagined some kind of pipeline for the request-response logic (I may still have some drawings on Google Docs). I guess this pipeline would be our "execution flow". If an exception is thrown, an outer middleware of the pipeline (which is responsible for error handling) can catch that exception and continue the execution of the rest of the pipeline.

[WanWizard]

Ok, I may have misunderstood you. I was under the impression that on a 404 exception, you always wanted to output the HTML. Which of course goes horribly wrong if the Controller is part of a REST API and the caller always expects a JSON response.

[emlynwest]

My thinking was that a 404 exception being thrown and not caught by the developer's application would then simply trigger the normal 404 handling, the result getting returned however has been defined by config or w/e.