-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LoggingThriftMethodInterceptor exception wrapping #26
Comments
Hi, could you provide real stacktraces on client side and server side? |
Thrift generated sources always declare a
An implementing class is usually overriding the method with declaring only a custom exception. Since it never throws a
In runtime, methods of the implementing class are proxied by Possible workarounds:
This will lead to TTransportException with
I've provided logs here: logs.zip
It might be useful to merge these tests into master. |
Hmm, maybe it's worth deleting any exception wrapping from EDIT: You will actually still get |
Hi! I see that
LoggingThriftMethodInterceptor
wraps any exception into aTApplicationException
inafterThrowing()
,TApplicationException
being a checked exception. I did a small refactoring of that class and have just left this code as it was. But now it's bothering me. If my callee code results in some runtime exception, the exception chain gets ugly:SomeRuntimeException
->TApplicationException
->java.lang.reflect.UndeclaredThrowableException: null
(!) ->org.apache.thrift.transport.TTransportException: HTTP Response code: 406
Maybe it's worth changing the exception type to some runtime exception subclass? The problem is, all
libthrift
exceptions are checked.The text was updated successfully, but these errors were encountered: