Throwing exceptions from records

[Brian Goetz]

Ty;

I think this discussion has largely run its course, and is threatening 
to stray outside of the bounds of what this list is for.

As a reminder, this list is for those involved in the _development_ of 
the Amber features.  We consider "experience reports" to be a valid (and 
often, highly valuable) contribution from that perspective, to the 
extent they are grounded in the concrete: "I tried X, and Y worked, but 
Z didn't."

I'd summarize the useful part of your feedback as follows:

  - It might be reasonable to allow record constructors to throw checked 
exceptions, since they already can throw unchecked exceptions (though, 
you don't really provide much in the way of concrete examples, just that 
you are worried about calling exception-throwing code from the ctor 
(though, as Kasper said, this is a sign you might be using the wrong 
tool in the first place))

Which is fine as far as it goes, and we'll take a note to discuss this 
in the EG.  The rest is, let's just say, "out of scope" for this list.

You also received some excellent advice from more experienced developers 
such as Remi and Kasper, which you seem more interested in arguing with 
than being educated by.  Which is fine, but don't do it here, that's not 
what this list is for.





On 3/9/2020 3:27 PM, Ty Young wrote:
>
> On 3/8/20 4:10 AM, Kasper Nielsen wrote:
>>> Right, because any and all meaningful logic is just thrown in other
>>> places making them more complicated.
>>>
>> I took a look at one of the classes you are trying to convert to a 
>> record [1].
>> And it really looks like a really poor fit for record conversion.
>
>
> Why?
>
>
>>   What exactly
>> are you trying to accomplish? Avoid writing a single getter?
>
>
> No. The point is to signify that the classes merely contain data.
>
>
>>   Because something
>> like equals() and toString() doesn't really make sense.
>
>
> Again, why? You claim things but provide zero reasons as to why.
>
>
>>   Also, by converting to
>> records you would end up exposing the VarHandle which I assume is 
>> something
>> you would actually want to encapsulate?
>
>
> It's exposed anyway?
>
>
>>   On top of that, you have a set method,
>> which I find really weird given that records signal pure data carriers.
>
>
> There is no "set" method, only an action, "call".
>
>
> And what is a "pure data carrier" exactly? I don't see any concrete 
> definition by anyone. No one said you couldn't have actions or setters 
> which modify a records field's fields.
>
>
> Also, why would a "pure" data carrier then need to have the ability to 
> implement interfaces? It introduces problems where an interface method 
> "getX()" could be different than just "x()".
>
>
>> /Kasper