Closed defunerik closed 10 years ago
Not sure what is the reason of this case-clause here. Probably an error coming from couchdb itself. Couchbeam does generally handle errors:
https://github.com/benoitc/couchbeam/blob/master/src/couchbeam.erl#L830
Can you provides a test that could help to reproduce the error?
implemented in latest couchbeam.
It has been frustrating receiving
{error,[],function_clause}
from couchbeam, with no indication of what the error is. This is pretty common for me when I'm putting views together by trial and error (couchbeam_view:fetch). This makes it terribly time consuming to debug views since I'm not getting any specific information back. I'm forced to run the raw queries against the couchdb server via an http client and inspect the results.After a few minutes of poking around couchbeam_view, it looks like this is because the
Callback
set up inview_loop
and provided toprocess_view_results
only handles status codes of 200, whereas process_view_results will pass the results to the Callback if the status code is 200, 201, or 4xx.In my code I do occasionally have the need to look at specific error codes returned by couchdb. E.g. if a database does not exist.
First, I wanted to confirm that this is indeed the current behavior of couchbeam, and that there is not some other feature I'm missing, or if I'm misusing it somehow. I'll try to fix at least my own fork when I have some free time. Although I'm not quite sure how to get there, what I will need are tagged error codes (e.g. database_not_found) so that my view cases can handle specific error conditions (or at least report them with some useful information.) The built-in callback could be smart about status codes in the context of the api being used, or it could just return the raw codes for interpretation by the couchbeam user, since the json error structures may be more useful: e.g.
{"error":"not_found","reason":"no_db_file"}