incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <j...@couchbase.com>
Subject Re: Documented API does not work.
Date Thu, 27 Dec 2012 04:02:45 GMT

On Dec 25, 2012, at 2:01 AM, Robert Newson <rnewson@apache.org<mailto:rnewson@apache.org>>
wrote:

Scott is right that we should return well-formed error responses and
not stack traces (We're not J2EE, for goodness sake)

Agreed. This seems to me to be an endemic problem of Erlang programs — the pattern-matching
behavior in the language is extremely convenient but results in software that handles any
sort of incorrect input with a generic exception like “badmatch”. Which might be okay
if the software took care to catch all of those exceptions and map them into either app-specific
exceptions or some kind of error codes; but none of the Erlang code I’ve seen (mostly just
CouchDB) ever does that. One of the few pieces of Erlang code I wrote did carefully try to
catch such generic exceptions, but I was told by the reviewer that it was “not idiomatic”.

Someone should totally fix this particular bug. But in my experience there are dozens of other
similar ones in the CouchDB code. Coding in Erlang seems to breed these bugs, the same way
that coding in C breeds memory smashers.

Yes, I am a little bitter about this. CouchDB has the most absurdly verbose-but-incomprehensible
log messages. I have spent/wasted many hours trying to make sense of them.

Omitting the leading slash
in the path of an HTTP request line is pretty unusual these days
(because it's mandatory and almost everyone uses a library of some
sort)

Also agreed. IMHO anyone who doesn’t immediately realize that the path in an HTTP command
line must begin with a slash, does not have the expertise to be hand-crafting HTTP requests.
I’m not being snooty, I’m just saying that there are a lot of excellent HTTP libraries
for every conceivable programming language, and the only reason to avoid them is if you’re
an HTTP boffin who needs to do something very unusual.

—Jens


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