tag:blogger.com,1999:blog-22587889.post925246145306075098..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: CouchDB and Scala - Updates on scouchdbAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-22587889.post-39569413059653903692009-05-17T03:09:00.000+05:302009-05-17T03:09:00.000+05:30Martin -
Thanks a lot for contributing the patch. ...Martin -<br />Thanks a lot for contributing the patch. Looks a very useful feature. I will definitely include it in the trunk when I have some time.<br /><br />Cheers.<br />- DebasishAnonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-75750410904459831952009-05-17T02:17:00.000+05:302009-05-17T02:17:00.000+05:30Thanks for sharing scouchdb, I am finding it very ...Thanks for sharing scouchdb, I am finding it very useful. I have been hacking on it a bit today and have just sent you a patch (via the Google Code issue tracker) for a new feature -- storing the type name in the JSON so that you can automatically create beans of the right type when you pull a document out of the database. I hope you find it useful.<br /><br />Cheers, MartinAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-45822191330113475402009-05-12T10:18:00.000+05:302009-05-12T10:18:00.000+05:30Dustin:
That's precisely my point. Whether 404 is...Dustin:<br /><br />That's precisely my point. Whether 404 is an exception or not depends on the use case and the framework cannot throw indiscriminately. The 0.3 of dbDispatch has some interesting extensions (see my last comment and nathan's comment) which can be of help in providing meaningful contract. Let me see if I can get some time to work on it in scouchdb.<br /><br />- DebasishAnonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-19982716021187556112009-05-12T01:20:00.000+05:302009-05-12T01:20:00.000+05:30I'd have to look closer at dispatch to underst...I'd have to look closer at dispatch to understand your comments better, but I'll add that I don't like the idea of having to catch an exception if a 404 is returned, because a 404 might be something desirable (an exception, IMHO, implies undesireable behavior).<br /><br />Imagine that below, I expect a 404 or a 409 to be common, then this sort of thing is ugly and doesn't really describe what I'm trying to accomplish:<br /><br />try{<br /> ... match {<br /> case (200, _) => ...<br /> case (304, _) => ...<br /> }<br />} catch {<br /> n: Exception404 => ...<br /> f: Exception409 => ...<br /> e: Exception => ...<br />}Dustin Ted Whitneyhttps://www.blogger.com/profile/17414601526967838823noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-66898263312616447672009-05-12T00:03:00.000+05:302009-05-12T00:03:00.000+05:30Nathan -
Http#when and Http#also look good for ca...Nathan -<br /><br />Http#when and Http#also look good for canned error handling and Handler[T] looks perfect as an extension point to define custom request/response handlers. I will let u know how these work out in my case. <br /><br />- DebasishAnonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-20823542338509208692009-05-11T23:47:00.000+05:302009-05-11T23:47:00.000+05:30These concerns were the motivation for one of the ...These concerns were the motivation for one of the dozen recent Dispatch refactors; a StatusCode exception shouldn't be the only way to handle non-OK responses when using >> or ># or any operator. So those now return Handler[T], which is compatible not just with Http#apply in anticipation of OK responses, but also Http#when to set your own response-code expectations, or Http#also to use two handlers, like a predefined one and a block of your own design that can pattern-match against a response code, HttpResponse, and Option[HttpEntity]. (<A HREF="http://databinder.net/dispatch-src/Http.scala.html#11029" REL="nofollow">current Http x-ray</A>)<br /><br />My hunch is that Http#also is almost right for error handling but not quite, because you probably don't want to run both handlers in case of failure. And Http#when is just a nice way to throw StatusCode exceptions. But the good news is Handler[T] gives us the ability to define request-response handlers and apply them various ways, so the perfect Http#flexible-error-method can be added without breaking everything else.nathan_hhttps://www.blogger.com/profile/12427083977923133797noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-11654286686414373882009-05-11T22:19:00.000+05:302009-05-11T22:19:00.000+05:30actually this is one thing I have kept open till d...actually this is one thing I have kept open till date. I am still not sure what will be the best way to handle exceptions. Currently I am happy to keep it at the level that dbDispatch offers - raising dispatch.StatusCode to the client. I am slightly hesitant to create another hierarchy of exceptions on top of it. And does it make a lot of sense to just wrap dispatch.StatusCode into another wrapper class ? When I hit a 404 in a fetch, should I throw a custom NotFoundException to the client ? Or modify the return type of the by_id method to an Option[] type ? Would love to hear what people think of the approaches to handle exceptions.<br /><br />- DebasishAnonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-1626138176216971612009-05-11T22:11:00.000+05:302009-05-11T22:11:00.000+05:30I had been writing my own ad hoc CouchDB interface...I had been writing my own ad hoc CouchDB interface but it's not nearly as complete as this. I'll give it a try shortly.<br /><br />One thing that I was doing in my own libraries was returning an HTTP response code from the result of the operation. It was nice to match against it, like <br /><br />... match {<br /> case (201, _) => ...<br /> case (409, _) => ...<br />}<br /><br />-DustinDustin Ted Whitneyhttps://www.blogger.com/profile/17414601526967838823noreply@blogger.com