You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Tom <to...@gmail.com> on 2017/10/10 07:42:42 UTC
TException and cross-tests
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?
AW: TException and cross-tests
Posted by Jens Geyer <je...@hotmail.com>.
I can throw and catch it. What am I doing wrong?
Sent from mobile device, please ignore spelling mistakes.
________________________________
Von: Tom
Gesendet: 12.10.2017 07:22
An: dev@thrift.apache.org
Betreff: Re: TException and cross-tests
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 <je...@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 <ra...@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 <to...@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?
>>>
>
Re: TException and cross-tests
Posted by Tom <to...@gmail.com>.
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 <je...@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 <ra...@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 <to...@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?
>>>
>
Re: TException and cross-tests
Posted by Jens Geyer <je...@hotmail.com>.
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 <ra...@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 <to...@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?
>>
Re: TException and cross-tests
Posted by Tom <to...@gmail.com>.
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 <ra...@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 <to...@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?
>>
Re: TException and cross-tests
Posted by Randy Abernethy <ra...@apache.org>.
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 <to...@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?
>