Re: Sealed Exception

2021-09-24 Thread forax
- Original Message -
> From: "Brian Goetz" 
> To: "Tagir Valeev" 
> Cc: "Remi Forax" , "Zheka Kozlov" , 
> "amber-spec-experts"
> 
> 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  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  wrote:
>> 
>>> - Original Message -
 From: "Zheka Kozlov" 
 To: "amber-dev" 
 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
>>> 


Re: Sealed Exception

2021-09-24 Thread Brian Goetz
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  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  wrote:
> 
>> - Original Message -
>>> From: "Zheka Kozlov" 
>>> To: "amber-dev" 
>>> 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
>> 
>> 



Re: Sealed Exception

2021-09-24 Thread Tagir Valeev
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  wrote:

> - Original Message -
> > From: "Zheka Kozlov" 
> > To: "amber-dev" 
> > 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
>
>


Re: Sealed Exception

2021-09-24 Thread Remi Forax
- Original Message -
> From: "Zheka Kozlov" 
> To: "amber-dev" 
> 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