Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can we override default 500, 404 page ? #96

Open
Et7f3 opened this issue Aug 13, 2019 · 6 comments
Open

How can we override default 500, 404 page ? #96

Et7f3 opened this issue Aug 13, 2019 · 6 comments

Comments

@Et7f3
Copy link

Et7f3 commented Aug 13, 2019

So I could send for instance link to the api documentation for instance. Or styling my 404 pages.

@anuragsoni
Copy link
Collaborator

We'll need to allow overriding the default not_found handler so it'll be possible to override the default 404 page. I believe the 500 message comes from Cohttp

@Et7f3
Copy link
Author

Et7f3 commented Aug 26, 2019

If they occur when a execptio is launched opium could try ... with all exception then ? Or we should open issue on Cohttp and maybe httpaf (when opium will change his backend)

@anuragsoni
Copy link
Collaborator

I'd need to take a look at the cohttp implementation to see how they implement it. For httpaf i believe there is more work needed from the library to trap exceptions from user defined handlers.

In the meantime it should be possible to catch the exception inside the handlers and respond appropriately.

@anuragsoni
Copy link
Collaborator

Overriding the 404 makes sense to me since Opium provides the router. But trapping all exceptions inside opium might be a little weird as error handling for exceptions might vary for different usecases and it might be nicer for the user to decide what they want to do inside their app.

@Et7f3
Copy link
Author

Et7f3 commented Aug 26, 2019

Maybe add a try_all bool somewhere then that is false by default. Maybe inside App.empty

@anuragsoni
Copy link
Collaborator

I think trying to catch exceptions like this inside Opium still seems a little brittle. For error handling situations I still think that a handler should be responsible for catching the exceptions (if any) and deciding what response is sent. Failing that it should be possible to achive this from the call site by having a wrapper for respond and respond' where one could map a code to the response needed by the application.

At this point either of those options seem not suited to add to a library like opium.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants