Error Handling within endpoint coprocessors -- best practices?

[Andrew Mains <an...@upsight.com>]

Hi all,

I'm developing an endpoint coprocessor at the moment for one of our 
applications, and I'm trying to figure out the best means to handle 
errors within the coprocessor. A couple of requirements:

1. I don't want the coprocessor to ever be unloaded on an error (my 
assumption is that errors will generally be independent across queries, 
and that the coprocessor should attempt to serve other queries even if 
one fails).
2. I'd like to be able to recognize and handle certain application 
exception classes on the client side (BAD_REQUEST type cases, primarily)

For this, it seems like I have a couple of options:

1. Handle exceptions in the coprocessor using 
org.apache.hadoop.hbase.protobuf.ResponseConverter#setControllerException. 
This seems to be the method used by the example coprocessors in the 
codebase, and it has the nice property of not requiring me to represent 
the errors explicitly in my response type. On the other hand, docs for 
com.google.protobuf.RpcController#setFailed mention that it shouldn't be 
used for machine readable exceptions, which should instead be 
represented in the response type; this makes it difficult to extract the 
exception type on the client side.

2. Represent exceptions in the response type proto (e.g. message 
MyResponse { optional Return, optional Error }). This is a little bit 
less transparent than the previous approach, but allows me to handle the 
exceptions more flexibly.

3. A hybrid approach--use an explicit response in my response type proto 
for exceptions I care about, and setControllerException for everything else.

Any suggestions on the best practice here? As I said, the example 
coprocessors seem to prefer method 1, but they also don't allow for 
differentiating exception types on the client side, so I'm a bit unclear 
on the best way to do this.

Thank you very much for your time!

Andrew

Re: Error Handling within endpoint coprocessors -- best practices?

[Ted Yu <yu...@gmail.com>]

As far as I can tell, the hybrid approach is amenable to better exception
handling on client side,

Cheers

On Fri, Nov 13, 2015 at 8:24 PM, Andrew Mains <an...@upsight.com>
wrote:

> Hi all,
>
> I'm developing an endpoint coprocessor at the moment for one of our
> applications, and I'm trying to figure out the best means to handle errors
> within the coprocessor. A couple of requirements:
>
> 1. I don't want the coprocessor to ever be unloaded on an error (my
> assumption is that errors will generally be independent across queries, and
> that the coprocessor should attempt to serve other queries even if one
> fails).
> 2. I'd like to be able to recognize and handle certain application
> exception classes on the client side (BAD_REQUEST type cases, primarily)
>
> For this, it seems like I have a couple of options:
>
> 1. Handle exceptions in the coprocessor using
> org.apache.hadoop.hbase.protobuf.ResponseConverter#setControllerException.
> This seems to be the method used by the example coprocessors in the
> codebase, and it has the nice property of not requiring me to represent the
> errors explicitly in my response type. On the other hand, docs for
> com.google.protobuf.RpcController#setFailed mention that it shouldn't be
> used for machine readable exceptions, which should instead be represented
> in the response type; this makes it difficult to extract the exception type
> on the client side.
>
> 2. Represent exceptions in the response type proto (e.g. message
> MyResponse { optional Return, optional Error }). This is a little bit less
> transparent than the previous approach, but allows me to handle the
> exceptions more flexibly.
>
> 3. A hybrid approach--use an explicit response in my response type proto
> for exceptions I care about, and setControllerException for everything else.
>
> Any suggestions on the best practice here? As I said, the example
> coprocessors seem to prefer method 1, but they also don't allow for
> differentiating exception types on the client side, so I'm a bit unclear on
> the best way to do this.
>
> Thank you very much for your time!
>
> Andrew
>