You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Kyle Johnson (JIRA)" <ji...@apache.org> on 2016/04/20 02:03:25 UTC
[jira] [Updated] (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:all-tabpanel ]
Kyle Johnson updated THRIFT-3794:
---------------------------------
Attachment: THRIFT-3794-Split-Application-Protocol-Transport-exception-subtypes.patch
I have attached a proposed patch that achieves the exception split. Looking for feedback and improvements.
> 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
> Attachments: THRIFT-3794-Split-Application-Protocol-Transport-exception-subtypes.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)