[jira] [Commented] (THRIFT-3794) Split Delphi application, protocol and transport exception subtypes into separate exceptions

["Jens Geyer (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249542#comment-15249542 ] 

Jens Geyer commented on THRIFT-3794:
------------------------------------

First, I understand the objective, but .... 

The libraries including details like the exceptions are not by accident very similar across all languages supported by Thrift, rather this is by design: We want a similar layout for all libraries. That does not mean that we don't optimize on a per-language basis, but having certain things consistent (down to the exception codes IDs used) is considered a Good Thing™. Aside from the fact that it introduces a breaking change.



> 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)