If we ban
} catch (FooException e) {
throw new RuntimeException(e);
}
then there is a real chance that people will instead write
} catch (FooException e) {
System.out.println(e);
}
instead. So, let’s give them a good alternative, or just let them continue
writing "new RuntimeException”, which I don’t think is that bad.
Julian
> On Feb 13, 2019, at 1:33 PM, Enrico Olivelli <[email protected]> wrote:
>
> Vladimir,
>
> Il giorno mer 13 feb 2019 alle ore 21:49 Vladimir Sitnikov
> <[email protected] <mailto:[email protected]>> ha scritto:
>>
>> Hi,
>>
>> I've recently discovered that new RuntimeException(Throwable) results in a
>> duplicated error messages.
>> In fact Throwable#<init>(Throwable) just calls cause.getMessage() and uses
>> it as its own message.
>>
>> This makes exceptions harder to follow since the new RuntimeException(e) is
>> very often used just to overcome "checked exception" rule in Java.
>>
>> I've recently committed a deduplicate PR to Avatica:
>> https://github.com/apache/calcite-avatica/pull/84
>> As you can see, it removed "RuntimeException: ..." nonsense and it made
>> exceptions easier to understand. For instance, see
>> https://github.com/apache/calcite-avatica/pull/84/files#diff-d499001f31481c5f7151a81380c01a60L332
>>
>> I think we should avoid new RuntimeException(Throwable), and I wonder if we
>> should add that as a forbiddenapis rule.
>>
>> You can find a PR for *test* code:
>> https://github.com/apache/calcite/pull/1042
>>
>> I'm not sure if I should just go ahead and dodge new
>> RuntimeException(Throwable) from the main codebase as well.
>> Do you have any negative experience with sneaky-throws pattern?
>> I'm inclined to do so provided no-one objects within a week.
>
> I think sneaky-throws works well in your case, I mean to replace new
> RuntimeException(Throwable).
> The only problem is that users will find checked exception thrown in
> places where they aren't supposed to be thrown,
> anyway using RuntimeException is weird as well.
>
> So +1 from me
>
> just my 2 cents
> Enrico
>
>>
>> Vladimir
