Throwing exceptions from records

[Ty Young]

On 3/9/20 4:12 PM, Brian Goetz wrote:
>
>
>>> I think this discussion has largely run its course, and is 
>>> threatening to stray outside of the bounds of what this list is for.
>>
>>
>> I was told that amber-dev was for discussion of records. I guess 
>> there was a miscommunication?
>
> Yes, perhaps the confusion is over the nature of said "discussion". 
> The charter of the -dev lists is for collaboration and discussion on 
> the _development_ of features in OpenJDK, not "any discussion 
> pertaining to records".


Is there a mailing list that is? I posted this on jdk-dev originally 
because it seemed to be a more laid-back, general list but, as I said, 
was told to post here. Right now there is discussion on preview features 
on jdk-dev that continues despite the official response seemingly being 
a resounding "no" to multiple people's requests for an official preview 
system.


>    As mentioned, constructive experience reports are always welcome, 
> but they need to stay within the bounds of relevance and 
> constructiveness, and you've surely found the bounds of both, and 
> you're being told to dial it back.
>
> For the record, a good guideline for when a non-development-related 
> comment is in bounds is: Is this telling the design or development 
> team something they are unlikely to already know?  Reporting bugs 
> almost always is; sharing concrete experience often is; undirected 
> complaining about features or disagreement with specific decisions 
> usually is not (we are already well aware that some people would 
> prefer a different choice for nearly any decision), and complaining 
> about process almost never is.  I realize interpreting these lines 
> require judgment, so this is your notice that you've gone way over 
> these lines.  (And, based on what's happened over on panama-dev, not 
> your first notice, or even close.)


I would be interested in a breakdown of such a judgement. I have been 
subscribed to many JDK mailing lists and have seen many presentations 
and/or emails by you and/or others wherein:


1. Some JDK developers being downright condescending(see the preview API 
discussion on jdk-dev for an example, wasn't even me calling it out)


2. Snarky comments between a JDK developer and another mailing list user 
about other mailing list members


3. Inappropriate, snide Jokes aimed at people on mailing lists during 
conferences/presentations


4. The deliberate attempt to kill civil(keyword here) discussion created 
by other people from JDK developers


Yet no warnings or "judgements" have been given.


Point is, JDK developers sometimes act and conduct themselves in ways 
that are seemingly unprofessional, unwelcoming, uncivil yet expect 
professional, welcoming, and civil behaviour from those outside the JDK 
developer circle. None of this is good for civil, rational discussion, 
yet it continues.


None of this is to say that I'm void of wrongdoing. I'm just saying, 
"rules for you, not for us" is what this feels like.


Anyway, majorly off-topic, I know.


>
>> No one has said otherwise nor has anyone layed down or linked to any 
>> other design documents that say my use case is wrong or invalid. 
>
> I think if you actually read what's been discussed on these lists, 
> you'd see that there has been a significant amount of discussion on 
> the "design center" for this feature, which could have informed your 
> judgment about whether you were working with, or against, the grain of 
> this feature.


I didn't know it was expected that anyone interested in participating in 
JDK mailing list discussion must be subscribed to every single list and 
had to be caught up on reading every single thread.


For the record, people other than myself have complained on panama-dev 
that just keeping up with Project Panama was too much for them... so I'm 
not the only one who is behind. Some people do Java programming on the 
side and just don't have time for mailing lists. I personally generally 
regard Project Amber to be that project where all the "bad" Java 
features are conjured up so I never joined, but thought records might be 
different.


>   (And others, who had been following, tried to suggest maybe you were 
> holding it wrong -- and instead of thanking them or constructively 
> engaging, you just argued and complained more.)  There is plenty of 
> information out there, but it might take some work to find. (But not 
> that much.)  Participating in the development is advanced stuff, and 
> if you want to play, you have to suit up.  (Or, if you don't want to, 
> that's fine -- but then please don't bother those who are doing the 
> work.)


I was genuinely asking for clarification as to why what they said was 
true. Apologies if that is how it came across, it 100% wasn't.


>
> Turning to your code, I agree with Kasper's intuition that you are 
> trying to use records for something they were not intended for. The 
> design center for records is (as has been stated many times) "nominal 
> tuples".  Is `nvmlInit` effectively a tuple?  Are the state-based 
> equals, hashCode, and toString methods a natural fit for the domain?  
> Is the canonical constructor enforcing any necessary invariants?  Are 
> you getting any benefit _at all_ from declaring as a record?  I don't 
> think so.  These are signs that this isn't the tool you are looking 
> for.  (BTW, you can use the compact form of the constructor here; you 
> don't need to write out `this.x = x`.)  Or, perhaps you might consider 
> whether records are helpful as the _implementation detail_ of your 
> class, by wrapping a record with the API you actually want to expose?


OK, thank you for the explanation. I guess when i read "record" I 
associate it with a document such as a medical(or similar) record... 
that is to say, something that is frozen in time and could be reproduced 
given the same information. Random people elsewhere do mention tuples 
when in conjunction with records, yes, but I didn't think that was the 
true purpose but rather a side affect or bonus feature. I take it the 
name is frozen and there is zero considerations for naming it to 
something more true to the intended meaning(tuple)?


>
> I suggest you go off and think about this stuff for a few weeks, read 
> what you can about the subject, and then if you still have questions, 
> and can express them constructively, consider trying again.
>