Which is precisely the source of confusion. I can't throw TException
over the protocol and expect it to be handled properly, since it's not
defined in the IDL and sending it is not part of the standard. Randy's
explanation confirms that.
On Thu, Oct 12, 2017 at 12:27 AM, Jens Geyer <jensge...@hotmail.com> wrote:
> There is a doc comment in the IDL file, actually:
>
> /**
> * Print 'testException(%s)' with arg as '%s'
> * @param string arg - a string indication what type of exception to throw
> * if arg == "Xception" throw Xception with errorCode = 1001 and message =
> arg
> * elsen if arg == "TException" throw TException
> * else do not throw anything
> */
> void testException(1: string arg) throws(1: Xception err1),
>
>
> -----Ursprüngliche Nachricht-----
> From: Tom
> Sent: Wednesday, October 11, 2017 7:20 AM
> To: dev@thrift.apache.org
> Subject: Re: TException and cross-tests
>
> Thank you for the thorough explanation. It clarified some bits of the
> exception system for me.
>
> I'm still not sure about that test I quoted, though - the
> testException one. My best guess is that when the client calls
> testException("TException"), the server should pass back an instance
> of Xception (which is the only thing it can technically "throw" for
> that function, unless we dig deeper into implementation details and
> try to force a TApplicationException, which is probably a horrible
> idea), and the client is supposed to catch it by establishing a
> handler for TException. So basically, this is to test the hierarchy on
> the client side. Is that right?
>
> On Tue, Oct 10, 2017 at 5:27 PM, Randy Abernethy <r...@apache.org> wrote:
>> Hi Tom,
>>
>> All Apache Thrift generated exceptions are derived from TException, not
>> just user defined exceptions. There are transport exceptions like
>> TTransportException which raise connectivity problems, TProtocolExceptions
>> for serialization errors, TApplicationExceptions for Server errors (e.g.
>> calling a function that does not exist) and user def exceptions for
>> application errors.
>>
>> TException is derived from the base exception type in the language in
>> question (if there is one).
>>
>> Processors catch only the handler exceptions declared in the exception
>> clause of the method in the service's IDL, any other exception escaping
>> the
>> handler will unwind the processor and possibly crash the server.
>> Exceptions
>> in the IDL exception list are passed back to the client by the processor.
>> The only other kind of exception passed back to the client is
>> TApplicationException which is used when a request is mechanically broken
>> (wrong protocol or transport setup, missing reqed args, etc.).
>>
>> The only user defined way to return an exception to a caller from a
>> handler
>> is to actually raise the exception (throw, whatever). Again the exception
>> must also be IDL defined and in the IDL exception list of the method in
>> question.
>>
>> -Randy
>>
>>
>> On Tue, Oct 10, 2017 at 12:42 AM, Tom <tomsand...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> We're working on Common Lisp support for Thrift. I've run into a
>>> little issue while implementing cross-tests - namely this bit:
>>>
>>> /**
>>> * Print 'testException(%s)' with arg as '%s'
>>> * @param string arg - a string indication what type of exception to
>>> throw
>>> * if arg == "Xception" throw Xception with errorCode = 1001 and
>>> message
>>> = arg
>>> * elsen if arg == "TException" throw TException
>>> * else do not throw anything
>>> */
>>> void testException(1: string arg) throws(1: Xception err1),
>>>
>>>
>>> Is there some specification on how TException is supposed to work? I
>>> understand it is a parent of any exception type defined by the user in
>>> the IDL file, but I thought that would be purely an implementation
>>> detail of specific languages so that they can make clauses that catch
>>> all user-defined errors they receive via Thrift. But apparently, it
>>> should be possible to send it explicitly via the protocol, without it
>>> being defined in the IDL?
>>>
>>> Or maybe it's meant to test the TApplicationException, as defined
>>> here: https://erikvanoosten.github.io/thrift-missing-
>>> specification/#_response_struct
>>> ? Supposed to be sent not like a user-defined exception (message type
>>> Reply), but with a message of type Exception?
>>>
>
