incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Paul (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (COUCHDB-1635) Error handling code in validate_doc_update assumes a string for the error value
Date Thu, 03 Jan 2013 19:24:12 GMT

     [ https://issues.apache.org/jira/browse/COUCHDB-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Travis Paul updated COUCHDB-1635:
---------------------------------

          Environment: CentOS 6.3 x86_64 (CouchDB RPM from EPEL)
    Affects Version/s: 1.0.3
    
> Error handling code in validate_doc_update assumes a string for the error value
> -------------------------------------------------------------------------------
>
>                 Key: COUCHDB-1635
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1635
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Futon, HTTP Interface
>    Affects Versions: 1.0.3
>         Environment: CentOS 6.3 x86_64 (CouchDB RPM from EPEL)
>            Reporter: Travis Paul
>         Attachments: forbidden_crash_report.txt, unauthorized_crash_report.txt
>
>
> CouchDB crashed when trying to throw the following objects from a validate_doc_update
function:
> throw({forbidden: [{}] });
> // will attach: forbidden_crash_report.txt
> throw({unauthorized : [{}] });
> // will attach: unauthorized_crash_report.txt
> It seems that the CouchDB error handling code assumes a string for the
> error value, futon does this as well.
> Robert Newson responded to me on the mailing list with:
> I can easily believe our error handling code assumes a string for the
> error value. File a JIRA ticket?
> error_info({Error, Reason}) when is_list(Reason) ->
>     error_info({Error, ?l2b(Reason)});
> This clause assumes, erroneously, that a list is really a string and
> so converts it to a binary. In this case, the list contains objects.
>  
> I decided to run some more tests before filing a bug:
> throw({forbidden: [] });
> // {"error":"forbidden","reason":""}
> throw({forbidden: {} }); 
> // {"error":"forbidden","reason":{}}
> // futon reports: Error: unauthorized [object Object]
> throw({unauthorized : [] });
> // {"error":"unauthorized","reason":""}
> throw({unauthorized : {} });
> // {"error":"unauthorized","reason":{}}
> // futon reports:  Error: unauthorized [object Object]
> throw({ foo: [{}] });
> // I'm not quite sure what to make of this result:
> // {"error":"case_clause","reason":"{[{<<\"foo\">>,[{[]}]}]}"}
> But I'm not 100% sure this is a bug, it may actually be somewhat of a feature request
as it seems Futon expects strings and the Definitive Guide suggests this is expected behavior:
> "When you’re trying to prevent an authorized user from saving invalid data, use this:
> throw({forbidden : message});"
> However crashing and not sending a response suggest that it is a bug.
> My use case is that I am trying to return an array of json-schema errors with all of
the validation errors instead of a single message.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message