abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James M Snell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ABDERA-132) AbstractProvider should have better error handling and reporting
Date Thu, 20 Mar 2008 15:09:26 GMT

    [ https://issues.apache.org/jira/browse/ABDERA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12580786#action_12580786

James M Snell commented on ABDERA-132:

Ok, this is partially resolved. I added the logging.  We'll need to revisit this later.  For
the most part, the code makes the assumption that the adapters will properly deal with error
handling and will return ResponseContext's with the proper HTTP response code, even in error

> AbstractProvider should have better error handling and reporting
> ----------------------------------------------------------------
>                 Key: ABDERA-132
>                 URL: https://issues.apache.org/jira/browse/ABDERA-132
>             Project: Abdera
>          Issue Type: Bug
>    Affects Versions: 0.4.0
>            Reporter: Jim Ancona
> AbstractProvider.process() wraps all of its code in a "catch (Throwable e)", which returns
a 500 status and doesn't log the exception.
> At a minimum, it should log the exception. It should also attempt to distinguish internal
errors from those caused by bad requests, which arguably should return a 400. For example,
in my case, accidentally passing a content type of "UTF-8" caused a MimeTypeParseException.
A 400 status would have made it more clear that the problem was in my client code.

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

View raw message