Gilles Sadowski wrote: >>>>> A simpler policy would be to not check for "null" and let the JVM do it. >>>>> As >>>>> the JVM will do it anyway, it's a redundant check when the reference is >>>>> not >>>>> null, i.e. most of time (in legitimate usage). >>>> This simpler policy seems fine to me. >>>> However, it is an important change from previous behaviour. >> Sorry, I am not sure I understand what you mean by the "simpler >> policy." Which one do you mean: >> >> 0) remove null checks uniformly and just let NPEs propagate everywhere > > Yes. > >> 1) remove NPE wrappers, propagating uwrapped NPEs where the code >> wraps and rethrows NPE today. > > I don't understand this. I didn't find occurrences where a NPE is wrapped > into something else.
I was referring to the MathRuntimeExceptions. > >> 2) other? >> >> I am -1 on 0), since this would result in loss of FFC info available >> in the cases where we rethrow NPE as IAE with an exception message >> indicating which argument was null (like the examples below). > > What does FFC mean? First failure capture - information available to the caller when a failure occurs. If we do not generate a message or persist in an exception property an indication of what argument was null, we remove information that is available to the caller today. We have discussed this before. I am in general OK with changing the way we manage localization, etc., but -1 on removing information from stack traces. > I think that using IAE instead of NPE does not bring any added value. It > justs goes against standard usage: throw NPE when a reference is "null" > and is not allowed to be so. > As proposed in > https://issues.apache.org/jira/browse/MATH-401 > we could still do explicit checks for "null" but nevertheless throw the > standard (non-specific and non localized) NPE. > The added value that I see is that an IAE designating which argument that cannot be null is in fact null gives more specific information to the caller (or production support person examining logs) than just a propagated NPE. Phil >> [...] > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
