Double fault catchers to allow catchers to access the state.

[Arignir]

Hello,

As far as I know, the current implementation forbids catchers to be dynamic, which prevent the website to implement a nice error-page with infused template depending on dynamic parameters (like a navbar that shows the user login and picture)

The reasoning given in PR #222 was

Error catchers cannot fail. They are meant to catch, not handle errors. That is, they are a sink for errors that aren't handled elsewhere. If you need custom error handling, you can use forwarding and/or Result return types to handle this.

Therefore, if we want a dynamic catcher that does nice and pretty things, the recommended implementation is for each route to:

Return a Result<T, status::Custom>, where maybe T and E are both Template, or something else entirely. Then you can set the status code and emit whatever custom response you'd like.

Unless I misunderstand what you're saying, this looks like a hackish, painful solution that requires a lot of boilerplate code for a simple problem.

Also, it won't work for 404 handlers unless an extra "match-all" route is added that returns a Template with a custom http code (which defeats the purpose of registering a catcher in the first place)

To answer that problem, I propose a system similar to what most CPU do when an exception is raised within an exception handler: a double fault handler.

Rocket could allow a catcher to access the usual dynamic parameters like the state, cookies, etc., like any other route. Therefore, such catchers could (and would be allow) to fail.

If a catcher fail, an extra "double fault" catcher is called which has the same restriction than the current ones: it cannot fail and therefore cannot access the current state. This prevent infinite recursion of catchers.

I think this solution is both elegant and powerful. What do you think?

[jebrosen]

As far as I know, the current implementation forbids catchers to be dynamic

Rocket could allow a catcher to access the usual dynamic parameters like the state, cookies, etc., like any other route. Therefore, such catchers could (and would be allow) to fail.

You may have missed this: it is possible to manually invoke any and all request guards, including State and Cookies, via Request::guard().

It's not possible to pass any kind of data directly from a route to an error catcher. This is one of the motivations for using Result<T, E> where T and E both implement Responder. It could still probably be done with request-local state if you really wanted to.

There was a design idea that would allow routes to pass an error value (like SomeError in Result<SomeResponder, SomeError> directly to an error catcher (#[catch(400)] fn catch_400(error: SomeError)), but it's currently impossible because of limitations of the rust language and hasn't been revisited in a while.

[Arignir]

Oh, i did in fact missed this. Thanks!