You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Hudson (JIRA)" <ji...@apache.org> on 2016/05/03 05:13:13 UTC
[jira] [Commented] (THRIFT-3794) Split Delphi application, protocol
and transport exception subtypes into separate exceptions
[ https://issues.apache.org/jira/browse/THRIFT-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268004#comment-15268004 ]
Hudson commented on THRIFT-3794:
--------------------------------
SUCCESS: Integrated in Thrift-precommit #451 (See [https://builds.apache.org/job/Thrift-precommit/451/])
THRIFT-3794 Fixing exception types in library now that they have been (jensg: [https://github.com/apache/thrift/commit/e363a34e63e851f17061a912a77e75a8ed8474bc])
* lib/delphi/src/Thrift.Transport.pas
* lib/delphi/src/Thrift.Socket.pas
> Split Delphi application, protocol and transport exception subtypes into separate exceptions
> --------------------------------------------------------------------------------------------
>
> Key: THRIFT-3794
> URL: https://issues.apache.org/jira/browse/THRIFT-3794
> Project: Thrift
> Issue Type: Improvement
> Components: Delphi - Library
> Reporter: Kyle Johnson
> Assignee: Kyle Johnson
> Fix For: 0.10.0
>
> Attachments: THRIFT-3794-Split-Application-Protocol-Transport-exception-subtypes.patch, THRIFT-3794-Split-Delphi-application-protocol-and-tr.patch
>
>
> It is much more convenient to work with a hierarchy of exceptions for several reasons, including, but not limited to the following:
> 1) Writing exception handler filters is much simpler and clearer when one can simply say "on E: TTransportExceptionTimedOut do" instead of "on E: TTransportException do if E.Type_ = TTransportException.TExceptionType.TimedOut then".
> 2) Ignoring exception types within the Delphi IDE is doable, but not by exception subtype, as with the Delphi library. It isn't possible to ignore transport timeouts and not ignore all other transport exception subtypes. This makes debugging much more challenging when stepping through code.
> I propose splitting the TApplicationException, TProtocolException and TTransportException classes into separate exception classes based on exception subtype. It should be possible to do so while retaining backward compatibility for code that relies on the old exception methodology.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)