[
https://issues.apache.org/jira/browse/THRIFT-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-4562:
-------------------------------
Description:
h2. Problem
# In contrast to other languages, there is no real way to prevent Delphi from
inheriting unwanted CTORs.
# The generated code initializes an "exception factory" helper object used for
serializing the exception info over the wire. This helper object is
instantiated in two cases:
** a) in the CTORs that are defined in the exception class
** b) when a property setter is called on that instance
h2. Example
The following IDL:
{code:java}
exception ApiException {
1: string Msg
2: i32 Error
}
{code}
results in this Delphi code:
{code:java}
TApiException = class(TException)
// ... some unrelevant details omitted ...
public
constructor Create; overload;
constructor Create( const AMsg: System.string; AError: System.Integer);
overload;
// ... more code ...
end;
{code}
Due to the inheritance from {{TException}} and finally {{System.Exception}}, a
bunch of other CTORs is inherited, such as:
{code:java}
constructor Create(const Msg: string);
{code}
>From this, a situation may arise, in which the developer instantiates the
>instance by calling one of the inherited CTORs (which do not intialize the
>Factory helper object), then raising the exception without assigning any other
>values via property setter:
{code}
raise TApiException.Create('some error occurred!'); // inherited CTOR
{code}
instead of
{code}
raise TApiException.Create('some error occurred!', 42); // TApiException CTOR
{code}
Under these circumstances, the Factory helper object is left at its default
value of {{nil}}, hence no suitable information is written to the wire. As a
direct result, being unable to deserialize anything useful on return, the
client code will run into the default catcher code which raises an generic
TApplicationException with {{MissingResult}} code and the "call failed: unknown
result" message.
was:
h2. Problem
# In contrast to other languages, there is no real way to prevent Delphi from
inheriting unwanted CTORs.
# The generated code initializes an "exception factory" helper object used for
serializing the exception info over the wire. This helper object is
instantiated in two cases:
** a) in the CTORs that are defined in the exception class
** b) when a property setter is called on that instance
h2. Example
The following IDL:
{code:java}
exception ApiException {
1: string Msg
2: i32 Error
}
{code}
results in this Delphi code:
{code:java}
TApiException = class(TException)
// ... some unrelevant details omitted ...
public
constructor Create; overload;
constructor Create( const AMsg: System.string; AError: System.Integer);
overload;
// ... more code ...
end;
{code}
Due to the inheritance from {{TException}} and finally {{System.Exception}}, a
bunch of other CTORs is inherited, such as:
{code:java}
constructor Create(const Msg: string);
{code}
>From this, a situation may arise, in which the developer instantiates the
>instance by calling one of the inherited CTORs (which do not intialize the
>Factory helper object), then raising the exception without assigning any other
>values via property setter:
{code}
raise TApiException .Create('some error occurred!'); // inherited CTOR
{code}
instead of
{code}
raise TApiException .Create('some error occurred!', 42); // TApiException CTOR
{code}
Under these circumstances, the Factory helper object is left at its default
value of {{nil}}, hence no suitable information is written to the wire. As a
direct result, being unable to deserialize anything useful on return, the
client code will run into the default catcher code which raises an generic
TApplicationException with {{MissingResult}} code and the "call failed: unknown
result" message.
> Calling wrong exception CTOR leads to "call failed: unknown result" instead
> of the real exception being thrown
> --------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-4562
> URL: https://issues.apache.org/jira/browse/THRIFT-4562
> Project: Thrift
> Issue Type: Bug
> Components: Delphi - Compiler
> Reporter: Jens Geyer
> Priority: Major
>
> h2. Problem
> # In contrast to other languages, there is no real way to prevent Delphi from
> inheriting unwanted CTORs.
> # The generated code initializes an "exception factory" helper object used
> for serializing the exception info over the wire. This helper object is
> instantiated in two cases:
> ** a) in the CTORs that are defined in the exception class
> ** b) when a property setter is called on that instance
> h2. Example
> The following IDL:
> {code:java}
> exception ApiException {
> 1: string Msg
> 2: i32 Error
> }
> {code}
> results in this Delphi code:
> {code:java}
> TApiException = class(TException)
> // ... some unrelevant details omitted ...
> public
> constructor Create; overload;
> constructor Create( const AMsg: System.string; AError: System.Integer);
> overload;
> // ... more code ...
> end;
> {code}
> Due to the inheritance from {{TException}} and finally {{System.Exception}},
> a bunch of other CTORs is inherited, such as:
> {code:java}
> constructor Create(const Msg: string);
> {code}
> From this, a situation may arise, in which the developer instantiates the
> instance by calling one of the inherited CTORs (which do not intialize the
> Factory helper object), then raising the exception without assigning any
> other values via property setter:
> {code}
> raise TApiException.Create('some error occurred!'); // inherited CTOR
> {code}
> instead of
> {code}
> raise TApiException.Create('some error occurred!', 42); // TApiException
> CTOR
> {code}
> Under these circumstances, the Factory helper object is left at its default
> value of {{nil}}, hence no suitable information is written to the wire. As a
> direct result, being unable to deserialize anything useful on return, the
> client code will run into the default catcher code which raises an generic
> TApplicationException with {{MissingResult}} code and the "call failed:
> unknown result" message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
