[
https://issues.apache.org/jira/browse/COUCHDB-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Leeds closed COUCHDB-336.
---------------------------------
Resolution: Won't Fix
No update in well over a year. I looked into this in light of my recent
attempts to clean up JS error reporting. I think it's debatable whether or not
this type of error should be sent to the client at all.
It's not a matter of evalcx not reporting the error. The error is reported,
it's just not reported through to HTTP. Doing so would require a major change
to the way errors behave in the map/reduce indexer. Since re-requesting a view
like this does not cause the error to be logged in the couch.log if the index
is already built, in order to really change this we would have to cause the
whole index to be invalid whenever any errors are throw while mapping any
documents. That seems to me like a nasty thing to do to people.
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
