[
https://issues.apache.org/jira/browse/THRIFT-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17900533#comment-17900533
]
Jens Geyer edited comment on THRIFT-5837 at 11/23/24 12:23 AM:
---------------------------------------------------------------
The new design has completely changed internally:
* the exception factory is gone
* the exception data are held in a dedicated data instance (a simple
straightforward Thrift struct) and no longer in the exception class itself
* that struct is also used when the exception data are used as a simpe struct
This Thrift IDL
{code:java}
exception Error {
1: i32 ErrorCode
2: Error InnerException
}
{code}
produces three classes/interfaces:
{code:java}
// exception data as struct
IError = interface(IBase) .... end;
// the data class that implements IError and holds all data
TErrorImpl = class(TInterfacedObject, IBase, ..., IError) .... end;
// the exception class is only used when the exception is really used as such,
i.e. thrown and caught.
TError = class(TException, IInterface, IBase, ISupportsToString) .... end;
{code}
The exception class {{TError}} offers this public API
{code:java}
TError = class(TException, IInterface, IBase, ISupportsToString)
public
constructor Create; overload;
constructor Create( aErrorCode: System.Integer; const aInnerException:
IError); overload;
constructor Create( const aData: IError); overload;
destructor Destroy; override;
property ExceptionData : IError read FData;
function ToString: string; override;
// IBase
procedure Read( const iprot: IProtocol);
procedure Write( const oprot: IProtocol);
// Properties
property ErrorCode: System.Integer read GetErrorCode write SetErrorCode;
property InnerException_: IError read GetInnerException write
SetInnerException_;
// isset -> omitted for brevity
end;{code}
{*}NOTE{*}: Despite implementing interfaces, {{TError}} still inherits from
{{Exception}} and therefore still and *very deliberately* is not refcounted.
Making an {{Exception}} descendant refcounted would cause all kinds of subtle
issues (invalid ptrs, memory leaks - you name it) because it interferes with
the Delpjhi "compiler magic" special logic around exception handling.
was (Author: jensg):
The new design is comnpletely changed internally:
* the exception factory is gone
* the exception data are held in a dedicated data instance (a simple
straightforward Thrift struct) and no longer in the exception class itself
* that struct is also used when the exception data are used as a simpe struct
This Thrift IDL
{code:java}
exception Error {
1: i32 ErrorCode
2: Error InnerException
}
{code}
produces three classes/interfaces:
{code:java}
// exception data as struct
IError = interface(IBase) .... end;
// the data class that implements IError and holds all data
TErrorImpl = class(TInterfacedObject, IBase, ..., IError) .... end;
// the exception class is only used when the exception is really used as such,
i.e. thrown and caught.
TError = class(TException, IInterface, IBase, ISupportsToString) .... end;
{code}
The exception class {{TError}} offers this public API
{code:java}
TError = class(TException, IInterface, IBase, ISupportsToString)
public
constructor Create; overload;
constructor Create( aErrorCode: System.Integer; const aInnerException:
IError); overload;
constructor Create( const aData: IError); overload;
destructor Destroy; override;
property ExceptionData : IError read FData;
function ToString: string; override;
// IBase
procedure Read( const iprot: IProtocol);
procedure Write( const oprot: IProtocol);
// Properties
property ErrorCode: System.Integer read GetErrorCode write SetErrorCode;
property InnerException_: IError read GetInnerException write
SetInnerException_;
// isset -> omitted for brevity
end;{code}
{*}NOTE{*}: Despite implementing interfaces, {{TError}} still inherits from
{{Exception}} and therefore still and *very deliberately* is not refcounted.
Making an {{Exception}} descendant refcounted would cause all kinds of subtle
issues (invalid ptrs, memory leaks - you name it) because it interferes with
the Delpjhi "compiler magic" special logic around exception handling.
> Delphi implementation for THRIFT-5835
> -------------------------------------
>
> Key: THRIFT-5837
> URL: https://issues.apache.org/jira/browse/THRIFT-5837
> Project: Thrift
> Issue Type: Sub-task
> Components: Delphi - Compiler
> Reporter: Jens Geyer
> Assignee: Jens Geyer
> Priority: Major
>
> *Premise*: Rewrite entire exception code internally to implement THRIFT-5835
> but don't break existing code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
