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