You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by "James M Snell (JIRA)" <ji...@apache.org> on 2008/03/20 16:09:26 UTC

[jira] Commented: (ABDERA-132) AbstractProvider should have better error handling and reporting

    [ 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 conditions.

> 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.