You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Brian Candler (JIRA)" <ji...@apache.org> on 2009/05/05 23:23:36 UTC

[jira] Commented: (COUCHDB-336) Would like errors in map function to be reported to client

    [ https://issues.apache.org/jira/browse/COUCHDB-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706200#action_12706200 ] 

Brian Candler commented on COUCHDB-336:
---------------------------------------

As an additional point: the error messages currently returned for a badly-formed map or reduce function are not as good as the standalone js is capable of producing. For example:

$ curl -X POST -d '{"map":"function(doc){val val=doc.k; emit(val||null,null);}"}' http://127.0.0.1:5984/test/_temp_view
{"error":"compilation_error","reason":"expression does not eval to a function. (function(doc){val val=doc.k; emit(val||null,null);})"}

It's very common for a syntax error to return only "expression does not eval to a function". However, pasting the same code into js gives a much more informative error, indicating both the nature of the error and its location.

js> function(doc){val val=doc.k; emit(val||null,null);}
typein:1: SyntaxError: missing ; before statement:
typein:1: function(doc){val val=doc.k; emit(val||null,null);}
typein:1: ..................^


> Would like errors in map function to be reported to client
> ----------------------------------------------------------
>
>                 Key: COUCHDB-336
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-336
>             Project: CouchDB
>          Issue Type: Wish
>         Environment: svn trunk 0.10.0a768591
>            Reporter: Brian Candler
>            Priority: Minor
>
> At the moment, if a runtime error occurs in a map function, the document is silently excluded from the view and the client is none the wiser.
> $ curl -X PUT http://127.0.0.1:5984/test
> {"ok":true}
> $ curl -d '{"foo":"bar"}' -X PUT http://127.0.0.1:5984/test/doc1
> {"ok":true,"id":"doc1","rev":"1-3413565576"}
> $ curl -d '{"food":"bar"}' -X PUT http://127.0.0.1:5984/test/doc2
> {"ok":true,"id":"doc2","rev":"1-2088327893"}
> # Example 1: map function calls undefined function
> $ curl -d '{"map":"function(doc) { emitt(null,null); }"}' -H 'Content-Type: application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":0,"rows":[]}
> # Example 2: map function attempts to emit 'undefined'
> $ curl -d '{"map":"function(doc) { emit(doc._id,doc.foo); }"}' -H 'Content-Type: application/json' -X POST http://127.0.0.1:5984/test/_temp_view
> {"total_rows":1,"offset":0,"rows":[
> {"id":"doc1","key":"doc1","value":"bar"}
> ]}
> Of course, errors are available in the server log:
> [Tue, 28 Apr 2009 08:40:39 GMT] [info] [<0.1276.0>] OS Process Log Message: function raised exception (ReferenceError: emitt is not defined) with doc._id doc1
> [Tue, 28 Apr 2009 08:43:44 GMT] [info] [<0.1276.0>] OS Process Log Message: function raised exception (Cannot encode 'undefined' value as JSON) with doc._id doc2
> But the client cannot see these, and worse, gets what appears to be a valid result set.
> I think there are two cases to consider.
> - in temporary views, it ought to be easy to do something: e.g. (1) return the full set of failed docs with their errors, or (2) return a count of failed docs, or (3) just abort on the first error
> - in permanent views, it might also be useful to return this information, but it could be expensive to persist. Also, when you're querying for key X you might not want to see a whole load of errors for unrelated docs. An error count might be OK though, similar to total_rows.
> The current behaviour may be useful, although I personally wouldn't want to rely on it, especially as it generates errors in the log. That is, I would rather be forced to rewrite example 2 as
>   function(doc) { if (doc.foo) { emit(doc._id, doc.foo); } }
> or
>   function(doc) { emit(doc._id, doc.foo || null); }
> as appropriate.
> Workaround: users can manually wrap each of their map functions in a catcher which emits a sentinel key/value pair containing the error. However they would still have to query the key range which includes the error messages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.