You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by "Jim Ancona (JIRA)" <ji...@apache.org> on 2008/03/19 19:58:25 UTC

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

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.

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

Posted by "James M Snell (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/ABDERA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James M Snell resolved ABDERA-132.
----------------------------------

    Resolution: Fixed

added a new createErrorResponse method to AbstractProvider that can be subclassed to customize the error response

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

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

Posted by "James M Snell (JIRA)" <ji...@apache.org>.
    [ 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.