incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Jelsma - Buyways B.V." <>
Subject Re: _show without docid returns 500 instead of 404
Date Tue, 01 Dec 2009 17:04:43 GMT
Hello Chris,

I'm glad you agree on my assumption that either the book or code is
wrong and i'm glad something can be done about it.

Creating a custom 404 respone inside the show function seems
inappropriate to me. Since show functions are without side-effects they
cannot rely on other components in rendering a proper response so
rendering a custom reusable error response is out of the question. And
besides, a 404 Not Found is - in my opinion - exactly what we need and
allows/forces for the caller to handle it properly.

In short, i concur. I would vote for the 404 reply and thus follow the
instructions in the book.


On Tue, 2009-12-01 at 08:44 -0800, Chris Anderson wrote:

> I think in this case the book is wrong (or maybe it is right and the
> code is wrong). In the case of a missing doc the code currently forces
> you to raise the 404 error from your show function.
> I think this was done so that you have the option to render your own
> 404 error message, instead of being stuck with CouchDB's JSON message.
> The arguments for the CouchDB handling 404 for you:
> It's simpler to program because CouchDB handles some major error
> handling for you (and properly)
> It's more efficient b/c your JS function is not called in the case of
> a missing docid.
> The arguments for the current system (handle your own errors) pretty
> much boil down to some increased flexibility. The flexibility of 404
> messages might be better handled outside of show functions anyway.
> I am leaning toward the description the book gives (which would mean a
> code change). If you convince me it should be changed, I'll change it.
> Is anyone relying on the ability of show functions to render their own
> 404s?
> The change would be simple, just remove a catch clause on
> couch_httpd_show.erl line 81.
> Chris

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message