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

Non-informative error when handler returns nil #20

Open
si14 opened this issue Nov 3, 2014 · 1 comment
Open

Non-informative error when handler returns nil #20

si14 opened this issue Nov 3, 2014 · 1 comment

Comments

@si14
Copy link
Contributor

si14 commented Nov 3, 2014

It's a common pattern for Ring handlers to return nil. However, when this is the case, coercion-middleware explodes with non-informative message:

java.lang.NullPointerException
    at fnhouse.middleware$response_walker$fn__5341.invoke(middleware.clj:90)
    at fnhouse.middleware$eval5351$coercion_middleware__5352$fn__5356$fn__5358.invoke(middleware.clj:113)
    at fnhouse.routes$eval4736$root_handler__4737$fn__4738$fnk4739__4745$fn__4746.invoke(routes.clj:131)
    at fnhouse.routes$eval4736$root_handler__4737$fn__4738$fnk4739__4745.invoke(routes.clj:128)
    at clojure.lang.AFn.applyToHelper(AFn.java:154)
    at clojure.lang.AFn.applyTo(AFn.java:144)
    at clojure.lang.AFunction$1.doInvoke(AFunction.java:29)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
...

It happens when anonymous function in response-walker gets nil for response. I don't know what would be better: to give more informative message there or to skip output coercion, assuming that there is an or somewhere upstream and other handler will be called or 404 will be raised.

Which approach is better and should I make a PR with fix?

@w01fe
Copy link
Member

w01fe commented Nov 4, 2014

Thanks for the report.

For now, fnhouse is structured so that the handler must always be uniquely determined by the route, so I'm not sure passing the nil through is the right thing (but very open to discussing options). The simplest option for now seems to be to make the error message better, for which a PR would definitely be welcome.

Thanks again!

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