> De: "John Rose" <john.r.r...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "Brian Goetz" <brian.go...@oracle.com>, "valhalla-spec-experts" > <valhalla-spec-experts@openjdk.java.net> > Envoyé: Jeudi 9 Avril 2020 23:07:10 > Objet: Re: null checks vs. class resolution, and translation strategy for > casts
> On Apr 9, 2020, at 1:58 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr | > fo...@univ-mlv.fr ] > wrote: >> I don't fully understand why not using checkcast because from the user POV >> the >> message will be better than just NPE. > When today I try unbox an Integer but encounter a null, > my experience is “NPE” rather than a more informative > “failed to unbox this int because you handed me a null”. > I agree, generally speaking, that messages should be more > informative. But surely the bar is low here, and “NPE” is > not out of bounds? Not if JEP 358 is enable, you have a NPE on Integer.intValue(). Anyway, it's not because error message can be improved in an area that it should not be there in another area. Users on the Java side are writing a cast, so having a class cast exception because the value is null seems to be a good error message. > That said, an indy-based solution has full information > about the use site, and can be coaxed to generate whatever > user experience we desire. And so would intrinsic based > solutions, of which I am favorable to some but not all. > Perhaps we want another (intrinsically optimized) version > of Objects::requireNonNull, which takes a second argument > that assists in generating a better diagnostic. yes, indy is a way to create any new bytecode, but it also has some restrictions, the major one being that you can not using it before it has been bootstrapped. > — John Rémi
