Re: [grpc-io] Re: [grpc-java] global exception handler on client-side

[evaliauka via grpc.io]

Thanks!

On Friday, January 11, 2019 at 4:39:53 AM UTC+3, Kun Zhang wrote:
>
> Yes it's public API and we guarantee it won't break within the same major 
> version.
>
> On Thursday, January 10, 2019 at 12:13:52 AM UTC-8, eval...@exadel.com 
> wrote:
>>
>> Is ClientCalls class part of public API? I.e. am I safe to assume that it 
>> won't have breaking changes as long as I'm using grpc 1.X?
>>
>
-- 


CONFIDENTIALITY
NOTICE: This email and files attached to it are 
confidential. If you
are not the intended recipient you are hereby notified 
that using,
copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have
received 
this email in error please notify the sender and delete this
email.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/0b8a0903-b09a-40de-acc2-35d496011652%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: [grpc-java] global exception handler on client-side

['Kun Zhang' via grpc.io]

Yes it's public API and we guarantee it won't break within the same major 
version.

On Thursday, January 10, 2019 at 12:13:52 AM UTC-8, eval...@exadel.com 
wrote:
>
> Is ClientCalls class part of public API? I.e. am I safe to assume that it 
> won't have breaking changes as long as I'm using grpc 1.X?
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/a54fed0e-84c6-4de5-a99e-1bd3c76ff1d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: [grpc-java] global exception handler on client-side

[evaliauka via grpc.io]

Is ClientCalls class part of public API? I.e. am I safe to assume that it 
won't have breaking changes as long as I'm using grpc 1.X?

-- 


CONFIDENTIALITY
NOTICE: This email and files attached to it are 
confidential. If you
are not the intended recipient you are hereby notified 
that using,
copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have
received 
this email in error please notify the sender and delete this
email.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/20d55688-d8e6-4d06-adaa-9d71ee128aba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: [grpc-java] global exception handler on client-side

['Eric Anderson' via grpc.io]

On Sat, Apr 14, 2018 at 5:49 AM, evaliauka via grpc.io <
grpc-io@googlegroups.com> wrote:

> What I want is to setup an exception converter once, and have it applied
> automatically to all grpc calls.
>

grpc-java doesn't support this, and it would be a bit weird because it
changes the API. Maybe it could be a feature/configuration of the stub, as
long as you only want to throw RuntimeExceptions. But it also seems like it
would bring confusion when used. I do understand the annoyance of dealing
with less-than-ideally-convenient exception types, but it seems "that's
Java."

The only real way to do this today is make your own stub type, and that
would imply code generation. You can make a "poor man's" stub by having
your users pass your code a MethodDescriptor (obtained via
YourServiceGrpc.getYourMethod()), at which point you could do any
conversion logic and then call the stub utilities like
ClientCalls.blockingUnaryCall().

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oMqq3r1f3hjroQkE31zAkVjir%3Dy8d5%2BSCzLVoWdRrTxUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] Re: [grpc-java] global exception handler on client-side

[evaliauka via grpc.io]

This is exactly what I'm trying to avoid - unwrapping 
StatusRuntimeException each time I expect an exception or each time I call 
a grpc stub method.
What I want is to setup an exception converter once, and have it applied 
automatically to all grpc calls.

On Thursday, March 29, 2018 at 7:00:07 PM UTC+3, Carl Mastrangelo wrote:
>
> Point of clarification:   Stubs throw exceptions, Calls and Call.Listeners 
> do not.   The stubs wrap the calls/listeners and convert Status and 
> Metadata trailers into an exception, but you don't have to.   
>
> In the code you linked, you can attach a cause to the Status and pass that 
> through in your interceptor.   The outer most exception the stub will get 
> is a StatusRuntimeException IIRC, but you can walk the causal chain to get 
> at your underlying.  (we don't really /throw/ other people's exceptions)
>
> On Thursday, March 1, 2018 at 11:35:58 AM UTC-8, eval...@exadel.com wrote:
>>
>> Carl,
>>
>> thanks for reply.
>>
>> However, I'm a bit confused as I don't see a way to return my custom 
>> exception from the listener to the calling code.
>> Throwing an exception from onClose simply swallows the exception and 
>> makes the call hang forever.
>> super.onClose() only accepts status and trailers. So, no way to pass my 
>> custom exception.
>>
>> I added client 
>> 
>>  
>> interceptor to the example project.
>>
>> Regards,
>> Eduard
>>
>> On Thursday, March 1, 2018 at 9:45:20 PM UTC+3, Carl Mastrangelo wrote:
>>>
>>> You need to add a ClientInterceptor too.  It will provide a listener 
>>> which overrides the onClose(Status, Metadata) method of a 
>>> ClientCall.Listener.There, you can check for your metadata row added by 
>>> the server, and return the proper type of error to the next listener in 
>>> your interceptor chain.
>>>
>>> On Thursday, March 1, 2018 at 1:10:36 AM UTC-8, eval...@exadel.com 
>>> wrote:

 Here's the example that shows what I'm trying to achieve - 
 https://github.com/cartmanez/grpc-java-by-example/tree/master/error-handling-example
 The idea is the following:
 I have a set of domain exception known by each microservice. There's a 
 mapping domain exception <-> StatusRuntimeException
 Server automatically converts domain exception into 
 StatusRuntimeException. That's done by server interceptor.
 And I'd like to convert it back to domain exception on the client side, 
 so that calling code does not need to worry about StatusRuntimeException 
 at 
 all and only works with domain exceptions.

 Thanks in advance.

 Regards,
 Eduard

 On Wednesday, February 14, 2018 at 10:01:36 PM UTC+3, Carl Mastrangelo 
 wrote:
>
> No updates.   If you can upload your code somewhere, it would be 
> clearer why the interceptor wouldn't work.  
>
> On Friday, February 9, 2018 at 5:52:34 AM UTC-8, eval...@exadel.com 
> wrote:
>>
>> Hi!
>>
>> Any updates on this?
>>
>> I checked version 1.9.0 and still don't see a way to do exception 
>> conversion in an interceptor. 
>> I now think of writing my own wrappers for all blocking stubs to 
>> perform exception conversion. That would allow not to check status codes 
>> across the application and just catch specific exceptions where needed.
>> However, having the ability to define an exception transformer 
>> globally for grpc client would of course make life easier.
>>
>> Thanks
>>
>
-- 


CONFIDENTIALITY
NOTICE: This email and files attached to it are 
confidential. If you
are not the intended recipient you are hereby notified 
that using,
copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have
received 
this email in error please notify the sender and delete this
email.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/c305d96f-bb55-4f03-9872-1138317a4491%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

['Carl Mastrangelo' via grpc.io]

Point of clarification:   Stubs throw exceptions, Calls and Call.Listeners 
do not.   The stubs wrap the calls/listeners and convert Status and 
Metadata trailers into an exception, but you don't have to.   

In the code you linked, you can attach a cause to the Status and pass that 
through in your interceptor.   The outer most exception the stub will get 
is a StatusRuntimeException IIRC, but you can walk the causal chain to get 
at your underlying.  (we don't really /throw/ other people's exceptions)

On Thursday, March 1, 2018 at 11:35:58 AM UTC-8, eval...@exadel.com wrote:
>
> Carl,
>
> thanks for reply.
>
> However, I'm a bit confused as I don't see a way to return my custom 
> exception from the listener to the calling code.
> Throwing an exception from onClose simply swallows the exception and makes 
> the call hang forever.
> super.onClose() only accepts status and trailers. So, no way to pass my 
> custom exception.
>
> I added client 
> 
>  
> interceptor to the example project.
>
> Regards,
> Eduard
>
> On Thursday, March 1, 2018 at 9:45:20 PM UTC+3, Carl Mastrangelo wrote:
>>
>> You need to add a ClientInterceptor too.  It will provide a listener 
>> which overrides the onClose(Status, Metadata) method of a 
>> ClientCall.Listener.There, you can check for your metadata row added by 
>> the server, and return the proper type of error to the next listener in 
>> your interceptor chain.
>>
>> On Thursday, March 1, 2018 at 1:10:36 AM UTC-8, eval...@exadel.com wrote:
>>>
>>> Here's the example that shows what I'm trying to achieve - 
>>> https://github.com/cartmanez/grpc-java-by-example/tree/master/error-handling-example
>>> The idea is the following:
>>> I have a set of domain exception known by each microservice. There's a 
>>> mapping domain exception <-> StatusRuntimeException
>>> Server automatically converts domain exception into 
>>> StatusRuntimeException. That's done by server interceptor.
>>> And I'd like to convert it back to domain exception on the client side, 
>>> so that calling code does not need to worry about StatusRuntimeException at 
>>> all and only works with domain exceptions.
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>> Eduard
>>>
>>> On Wednesday, February 14, 2018 at 10:01:36 PM UTC+3, Carl Mastrangelo 
>>> wrote:

 No updates.   If you can upload your code somewhere, it would be 
 clearer why the interceptor wouldn't work.  

 On Friday, February 9, 2018 at 5:52:34 AM UTC-8, eval...@exadel.com 
 wrote:
>
> Hi!
>
> Any updates on this?
>
> I checked version 1.9.0 and still don't see a way to do exception 
> conversion in an interceptor. 
> I now think of writing my own wrappers for all blocking stubs to 
> perform exception conversion. That would allow not to check status codes 
> across the application and just catch specific exceptions where needed.
> However, having the ability to define an exception transformer 
> globally for grpc client would of course make life easier.
>
> Thanks
>


-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/65827f38-bff1-4095-93d5-98e0c2bf2430%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

[evaliauka via grpc.io]

Carl,

thanks for reply.

However, I'm a bit confused as I don't see a way to return my custom 
exception from the listener to the calling code.
Throwing an exception from onClose simply swallows the exception and makes 
the call hang forever.
super.onClose() only accepts status and trailers. So, no way to pass my 
custom exception.

I added client 

 
interceptor to the example project.

Regards,
Eduard

On Thursday, March 1, 2018 at 9:45:20 PM UTC+3, Carl Mastrangelo wrote:
>
> You need to add a ClientInterceptor too.  It will provide a listener which 
> overrides the onClose(Status, Metadata) method of a ClientCall.Listener.
> There, you can check for your metadata row added by the server, and return 
> the proper type of error to the next listener in your interceptor chain.
>
> On Thursday, March 1, 2018 at 1:10:36 AM UTC-8, eval...@exadel.com wrote:
>>
>> Here's the example that shows what I'm trying to achieve - 
>> https://github.com/cartmanez/grpc-java-by-example/tree/master/error-handling-example
>> The idea is the following:
>> I have a set of domain exception known by each microservice. There's a 
>> mapping domain exception <-> StatusRuntimeException
>> Server automatically converts domain exception into 
>> StatusRuntimeException. That's done by server interceptor.
>> And I'd like to convert it back to domain exception on the client side, 
>> so that calling code does not need to worry about StatusRuntimeException at 
>> all and only works with domain exceptions.
>>
>> Thanks in advance.
>>
>> Regards,
>> Eduard
>>
>> On Wednesday, February 14, 2018 at 10:01:36 PM UTC+3, Carl Mastrangelo 
>> wrote:
>>>
>>> No updates.   If you can upload your code somewhere, it would be clearer 
>>> why the interceptor wouldn't work.  
>>>
>>> On Friday, February 9, 2018 at 5:52:34 AM UTC-8, eval...@exadel.com 
>>> wrote:

 Hi!

 Any updates on this?

 I checked version 1.9.0 and still don't see a way to do exception 
 conversion in an interceptor. 
 I now think of writing my own wrappers for all blocking stubs to 
 perform exception conversion. That would allow not to check status codes 
 across the application and just catch specific exceptions where needed.
 However, having the ability to define an exception transformer globally 
 for grpc client would of course make life easier.

 Thanks

>>>
-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/04cbd2a9-23d1-45d3-a94a-022df2bdc94f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

['Carl Mastrangelo' via grpc.io]

You need to add a ClientInterceptor too.  It will provide a listener which 
overrides the onClose(Status, Metadata) method of a ClientCall.Listener.
There, you can check for your metadata row added by the server, and return 
the proper type of error to the next listener in your interceptor chain.

On Thursday, March 1, 2018 at 1:10:36 AM UTC-8, eval...@exadel.com wrote:
>
> Here's the example that shows what I'm trying to achieve - 
> https://github.com/cartmanez/grpc-java-by-example/tree/master/error-handling-example
> The idea is the following:
> I have a set of domain exception known by each microservice. There's a 
> mapping domain exception <-> StatusRuntimeException
> Server automatically converts domain exception into 
> StatusRuntimeException. That's done by server interceptor.
> And I'd like to convert it back to domain exception on the client side, so 
> that calling code does not need to worry about StatusRuntimeException at 
> all and only works with domain exceptions.
>
> Thanks in advance.
>
> Regards,
> Eduard
>
> On Wednesday, February 14, 2018 at 10:01:36 PM UTC+3, Carl Mastrangelo 
> wrote:
>>
>> No updates.   If you can upload your code somewhere, it would be clearer 
>> why the interceptor wouldn't work.  
>>
>> On Friday, February 9, 2018 at 5:52:34 AM UTC-8, eval...@exadel.com 
>> wrote:
>>>
>>> Hi!
>>>
>>> Any updates on this?
>>>
>>> I checked version 1.9.0 and still don't see a way to do exception 
>>> conversion in an interceptor. 
>>> I now think of writing my own wrappers for all blocking stubs to perform 
>>> exception conversion. That would allow not to check status codes across the 
>>> application and just catch specific exceptions where needed.
>>> However, having the ability to define an exception transformer globally 
>>> for grpc client would of course make life easier.
>>>
>>> Thanks
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/b513705f-4c89-4e62-badd-12d49561dd60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

[evaliauka via grpc.io]

Here's the example that shows what I'm trying to achieve 
- 
https://github.com/cartmanez/grpc-java-by-example/tree/master/error-handling-example
The idea is the following:
I have a set of domain exception known by each microservice. There's a 
mapping domain exception <-> StatusRuntimeException
Server automatically converts domain exception into StatusRuntimeException. 
That's done by server interceptor.
And I'd like to convert it back to domain exception on the client side, so 
that calling code does not need to worry about StatusRuntimeException at 
all and only works with domain exceptions.

Thanks in advance.

Regards,
Eduard

On Wednesday, February 14, 2018 at 10:01:36 PM UTC+3, Carl Mastrangelo 
wrote:
>
> No updates.   If you can upload your code somewhere, it would be clearer 
> why the interceptor wouldn't work.  
>
> On Friday, February 9, 2018 at 5:52:34 AM UTC-8, eval...@exadel.com wrote:
>>
>> Hi!
>>
>> Any updates on this?
>>
>> I checked version 1.9.0 and still don't see a way to do exception 
>> conversion in an interceptor. 
>> I now think of writing my own wrappers for all blocking stubs to perform 
>> exception conversion. That would allow not to check status codes across the 
>> application and just catch specific exceptions where needed.
>> However, having the ability to define an exception transformer globally 
>> for grpc client would of course make life easier.
>>
>> Thanks
>>
>
-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/8679eb76-0cc1-4397-bb32-3c73eeb8dfc6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

['Carl Mastrangelo' via grpc.io]

No updates.   If you can upload your code somewhere, it would be clearer 
why the interceptor wouldn't work.  

On Friday, February 9, 2018 at 5:52:34 AM UTC-8, eval...@exadel.com wrote:
>
> Hi!
>
> Any updates on this?
>
> I checked version 1.9.0 and still don't see a way to do exception 
> conversion in an interceptor. 
> I now think of writing my own wrappers for all blocking stubs to perform 
> exception conversion. That would allow not to check status codes across the 
> application and just catch specific exceptions where needed.
> However, having the ability to define an exception transformer globally 
> for grpc client would of course make life easier.
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6edc192c-6a3a-44f5-946b-4262d558e669%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

[evaliauka via grpc.io]

Hi!

Any updates on this?

I checked version 1.9.0 and still don't see a way to do exception 
conversion in an interceptor. 
I now think of writing my own wrappers for all blocking stubs to perform 
exception conversion. That would allow not to check status codes across the 
application and just catch specific exceptions where needed.
However, having the ability to define an exception transformer globally for 
grpc client would of course make life easier.

Thanks

-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/136671f6-dc92-4b2b-b3b6-697b60ab4717%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

[evaliauka via grpc.io]

I have 1-2 channels and 1-12 stubs in 5 applications. Subs have up to 30 
methods, so I don't really consider writing wrappers manually as a viable 
option.
> Why not just do the conversion in an interceptor?
I'd be happy to know how. As far as I can see all interceptor 
methods(except cancel) can be called in other thread, even if they are 
called in the same thread, all exceptions are either swallowed or wrapped 
into StatusRuntimeException.



-- 


CONFIDENTIALITY NOTICE: This email and files attached to it are 
confidential. If you are not the intended recipient you are hereby notified 
that using, copying, distributing or taking any action in reliance on the 
contents of this information is strictly prohibited. If you have received 
this email in error please notify the sender and delete this email.

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/543b5be8-2472-43ca-a3fb-52493218c0b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [grpc-java] global exception handler on client-side

['Carl Mastrangelo' via grpc.io]

How many stubs / channels do you have?   Why not just do the conversion in 
an interceptor?

On Friday, September 29, 2017 at 6:19:27 AM UTC-7, eval...@exadel.com wrote:
>
> With grpc 0.15.0 some time ago I implemented client side exception handler 
> via spring aspect. It converts StatusRuntimeException from the upstream 
> service into my own domain exception and re-throws it. I find it quite 
> convenient as throughout the code I can catch particular exceptions I'm 
> interested in instead of always catching StatusRuntimeException.
>
> I consider switching to the latest (1.6.1) version, and the problem is 
> that client stubs have been made final and it is no longer possible to use 
> aspects.
> The only (and ugly) solution is to do exception conversion in *cancel* 
> method of SimpleForwardingClientCall(called from catch block in 
> blockingUnaryCall). But in my understanding cancel method is not supposed 
> to throw exceptions, especially in case when cancel is called by the client 
> code itself.
> For server-streaming calls it is not possible to catch-and-rethrow the 
> exception thrown from iterator at all. With 0.15.0 I wrap returned iterator 
> and override hasNext method to catch and re-throw the exception.
>
> Has anyone tried to solve the same problem?
> Maybe there are plans to include support for such cases in grpc?
>
> Thank you in advance.
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/a12a5286-a4d1-4aee-a7b5-2457f8031c13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.