You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Jens Geyer (JIRA)" <ji...@apache.org> on 2016/04/21 23:06:13 UTC
[jira] [Resolved] (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 ]
Jens Geyer resolved THRIFT-3794.
--------------------------------
Resolution: Fixed
Fix Version/s: 0.10.0
Committed.
I thought a while about rewriting it into exception factories but finally didn't do it.
> 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)