[
https://issues.apache.org/jira/browse/FLINK-5854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15878037#comment-15878037
]
ASF GitHub Bot commented on FLINK-5854:
---------------------------------------
Github user tillrohrmann commented on the issue:
https://github.com/apache/flink/pull/3368
Big +1 from my side. I think that more specific exceptions helps to make
people think more about the cause of an exception and, thus, also how it should
be handled. Especially the fact that we always catch `RuntimeException` when
having `throws Exception` in the method definition annoyed me a lot.
@uce I think we should not per se wrap all current `Exceptions` into a
`FlinkRuntimeException`. Better to do a case distinction here.
> Introduce some Flink-specific base Exception types
> --------------------------------------------------
>
> Key: FLINK-5854
> URL: https://issues.apache.org/jira/browse/FLINK-5854
> Project: Flink
> Issue Type: Improvement
> Components: Core
> Reporter: Stephan Ewen
> Assignee: Stephan Ewen
> Fix For: 1.3.0
>
>
> Going through the code, there are a lot of places where exception handling
> could be done a bit nicer, for example
> - Some methods do not declare exceptions at all in their signatures. They
> simply catch all and wrap it in a {{RuntimeException}}.
> - Some places declare overly generic that they throw {{Exception}}, even
> though they could very specifically type the exceptions they throw.
> I suggest to introduce two new basic exceptions, that at least help document
> a bit more what goes wrong:
> - {{FlinkException}} as a base class for checked exceptions that indicate
> that something related to using Flink went wrong. Letting a method throw
> {{FlinkException}} rather than {{Exception}} already helps to not include all
> of Java's runtime exceptions, which indicate programming errors, rather than
> situations that should be recovered.
> - {{FlinkUncheckedException}} as a Flink-specific subclass of
> {{RuntimeException}}. That one can come in handy in places where no
> exceptions were declared, for example when reusing an interface that does not
> declare exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
