I agree that this was just something we overlooked, though not necessarily with
the leap from there to “so of course we should fix it”; the incremental
return-on-complexity there is probably quite low, unless the spec fix is truly
trivial. As Tagir points out, this is at least currently something quite rare.
> On Sep 24, 2021, at 7:40 AM, Tagir Valeev <amae...@gmail.com> wrote:
>
> Agreed. Looks like this case was just overlooked. Abstract exception class
> is quite an unusual thing but probably it will be more useful with sealed
> classes.
>
> With best regards,
> Tagir Valeev.
>
> On Fri, Sep 24, 2021 at 4:45 PM Remi Forax <fo...@univ-mlv.fr> wrote:
>
>> ----- Original Message -----
>>> From: "Zheka Kozlov" <orionllm...@gmail.com>
>>> To: "amber-dev" <amber-...@openjdk.java.net>
>>> Sent: Vendredi 24 Septembre 2021 10:30:54
>>> Subject: Sealed Exception
>>
>>> Hi!
>>
>> CC amber-spec-experts
>>
>>>
>>> Java 17 compiler forces me to insert an unreachable catch block for the
>>> base Exception:
>>>
>>> public static void main(String[] args) {
>>> try {
>>> f();
>>> } catch (Ex1 e) {
>>> e.printStackTrace();
>>> } catch (Ex2 e) {
>>> e.printStackTrace();
>>> } catch (BaseEx e) {
>>> // Unreachable
>>> }
>>> }
>>>
>>> private static void f() throws BaseEx {
>>> }
>>>
>>> sealed abstract class BaseEx extends Exception permits Ex1, Ex2 {
>>> }
>>>
>>> Otherwise it doesn't compile. Was this decision intentional?
>>
>> I don't think so, it's something we have overlooked.
>>
>>> If yes, why? If not, can we fix it? I see this as an unfortunate
>> limitation.
>>
>> I agree, it should be fixed.
>>
>>>
>>> With best regards, Zheka Kozlov.
>>
>> Regards,
>> Rémi
>>
>>
