4 ms·

And even in this case, a method full of != null checks seems silly when you can just catch NullPointerExceptions and return the default, no? Also, Java is stat

• NateDad 14y ago
  The problem with catching an NPE is that you don't know what was null, so you can't know if it was expected or not. Was req null? Or was the NPE thrown from inside GetHeaders()? Or something else entirely?
  • prawks 14y ago
    Right, but in the provided example what was null doesn't seem to matter. Only that there was a null reference.
• justinsb 14y ago
  It's normally considered bad form to catch NPE, particularly if a simple (x == null) check is the alternative. But that's largely a code-style issue; each to their own. I'm not sure what you mean by your static typing comment; I don't see where dynamic typing would offer a better alternative to anything we're talking about here?
  • prawks 14y ago
    It just seems like in a statically typed language, users should be more aware of nulls and handling them. Maybe I'm being naive, but it seems inherent in the paradigm that you shouldn't be playing as loosely with null and not null pointers. You should be fully able to expect a value to be there or not, by virtue of the certainty of your types and your conventions. I suppose when you talk about a large codebase used by people who are unaware of your conventions then you can run into issues, but I'd imagine that either null serves a purpose in your system, or not. If it does, handle it with the appropriate logic, if not, you shouldn't have to worry. Dynamic typing would offer you the convention of inherently being uncertain about what you're receiving and being overly defensive about everything.