toward null-safe cookie cutter Comparators

[Arved Sandstrom]

Yes I did. I was not sure that was what Wanja was getting at...

Is it Wanja?

It seemed Wanja was saying that the codebase he/she is working with
nulls are commonly passed around if data was not "correct"; potentially
causing a null pointer exception somewhere else in the codebase... and
then just throwing that null pointer; and not catching it as early as
possible and replacing it with an Exception that contains some state
information and context for that Null Pointer.

Wanja, did I misunderstand you?

As I read it and understood it, the scenario is the very common one of
null value handling, where "null" is a problem value - you cannot
proceed any further on the happy path with it.

Did he flat out advocate re-throwing NPEs? I didn't see that, I saw him
talking about letting them bubble up without catching them at all. The
only thing that would catch them would be a global exception handler
that is looking for NPEs.

On the subject of catching them, and wrapping them in a "more useful"
exception that holds extra context information, that _sounds_ appealing,
but ask yourself always if the complete stack trace for the NPE doesn't
already tell you what you need to know. If not, the tactic of wrapping
with extra information may be appropraite, but then so might be always
logging the potentially offending method call with parameter
information. One size doesn't fit all.

You are assuming I have misidentified something.

Well, not assuming, I'm flat out saying it based on your own words. In
your previous response you conflated "fail fast" with "as early as
possible". To be more precise, you apparently think (or thought) that
"fail fast" _identically_ means catching locally.

Catching locally could be one way in which you fail fast. But then so is
a global exception handler - which you'll have seen from Jim Shore's PDF
then requires that you do not _handle_ locally, although you could
certainly catch locally, enhance, and re-throw a wrapper to the global
exception handler.

You could certainly catch locally *and* handle locally, which depending
on what you do in the handling may or may not be "fail fast". If you
attempt to proceed when you oughtn't, that's not fail fast.

But I guess by assuming that, you get a suitable springboard to
reiterate what was in the article. A useful rhetorical trick I suppose.

Rhetorical trick? We may have read the same PDF but we sure didn't
understand it the same way. So obviously I felt the need to mention
parts of it.

I never suggested otherwise.

In fact why would anyone suggest otherwise?

You don't need to turn me into a scarecrow to make your arguments and
describe how you revamp enterprise web applications so well.

I believe you are excellent developer; you don't need to insult me to
prove that.

No insults intended. Not even in this reply. This is a purely
professional discussion. It's a good and interesting discussion - this
entire topic is one with a great variety of useful perspectives and
opinions and approaches, and it's one of the most important topics in
writing quality software.

AHS