Sealed Exception

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "Zheka Kozlov" <orionllmain at gmail.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Vendredi 24 Septembre 2021 18:55:01
> Subject: Re: Sealed Exception

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

Not fixing interaction between features in a language, here exception and sealed classes has a cost in term of how people make their mind around a feature.
Having a non consistent story for a feature make people less inclined to use it.

Given that sealed classes is something pivotal to the introduction of pattern matching, i think we should cover the last mile in this case.

BTW, i don't thing we are very good at the moment at explaining where and why pattern matching should be used.

Rémi

> 
>> On Sep 24, 2021, at 7:40 AM, Tagir Valeev <amaembo at 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 <forax at univ-mlv.fr> wrote:
>> 
>>> ----- Original Message -----
>>>> From: "Zheka Kozlov" <orionllmain at gmail.com>
>>>> To: "amber-dev" <amber-dev at 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
>>>