On Dec 25, 2012, at 2:01 AM, Robert Newson <[email protected]<mailto:[email protected]>> 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
