hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HBase Review Board (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2907) [rest/stargate] Improve error response when trying to create a scanner on a nonexistant table
Date Wed, 06 Oct 2010 22:16:30 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918707#action_12918707

HBase Review Board commented on HBASE-2907:

Message from: "Andrew Purtell" <apurtell@apache.org>

bq.  On 2010-10-06 15:08:23, Jonathan Gray wrote:
bq.  > Looks good to me.  I think in other parts of code we'll do something like: if (e
instanceof SomeExceptionType) but I guess these two ways are basically equivalent?  Or the
instanceof way would cover more generic stuff like seeing if something is an IOE but would
work even if the actual constructed class was something else but that extended IOE.

Right, I was thinking of using Class.isAssignableFrom but forget if that reads left-to-right
or right-to-left so I gave up. instanceof is better than equality, I'll use it.

- Andrew

This is an automatically generated e-mail. To reply, visit:

> [rest/stargate] Improve error response when trying to create a scanner on a nonexistant
> ---------------------------------------------------------------------------------------------
>                 Key: HBASE-2907
>                 URL: https://issues.apache.org/jira/browse/HBASE-2907
>             Project: HBase
>          Issue Type: Improvement
>          Components: rest
>            Reporter: Kieron Briggs
>            Assignee: Andrew Purtell
>            Priority: Minor
>             Fix For: 0.20.7, 0.90.0
> Since 0.20.4, an attempt to create a scanner for a nonexistant table receives a "400
Bad Request" response with no furthur information. Prior to 0.20.4 it would receive a "500
org.apache.hadoop.hbase.TableNotFoundException: <table>" response with a stack trace
in the body.
> Neither of these is ideal - the 400 fails to identify what aspect of the request was
bad, and the 500 incorrectly suggests that the error was internal. Ideally the error should
be a 400 error with information in the body identifying the nature of the problem.

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

View raw message