6 ms·
I've worked with developers who use this pattern frequently for code execution. try{ .. business logic .. } catch (NullPointerException e) { .. else .. } Ra
by idbentley 8y ago
I've worked with developers who use this pattern frequently for code execution.
try{
.. business logic ..
} catch (NullPointerException e) {
.. else ..
}
Rather than a null guard. That's what occurred to me.
- AaronFriel 8y agoThis is arguably more robust, because "foo.bar.quux.doTheThing()" is three potential null pointer exceptions in a row, and the code to do consecutive testing is ugly and verbose.
- arethuza 8y agoHaving a try..catch round such code would seem sensible but to rely on that over normal checking seems spectacularly horrible.
- DC-3 8y agoThis is why Rust's '?' operator for error propagation is quite nice.
- hamandcheese 8y agoIt’s a code smell if you are calling a method chain that long at all.
- laythea 8y agoCannot agree with you more. I personally hate chained expressions. Awful for debugging too.
- wtetzner 8y agoIt's only awful for debugging because the tools are awful.
- laythea 8y agoThe tools for Java are greate (try C++ if you disagree). It's the code that is the problem here.
- wtetzner 8y agoThe tools for Java are much better than those for C++. However, claiming the code is the problem is silly. I'm not going to introduce a bunch of local variables just to appease a debugger. If splitting on separate lines makes code more readable, then sure, do that. But often it just makes the code longer and harder to follow.
- xxs 8y agoJava debugging tools are beyond excellent for debugging such code (not that it should be written that way)
- laythea 8y agoI still have to select the sub-expression whose value I wish to inspect. This involves precisely aiming the cursor at text, which is a lot of mental burden (x millions). A task I thank the developer who creates a variable to hold such a reference, for it creates a much better experience.
- xxs 8y agoI guess there are extremely few people in the topic who understand how NPE works internally. There is no null check in the generated assembly code, when a null dereference occurs - it's an effective kernel trap (as 0 is not mapped to the process). The latter uses the code execution pointer to understand what has been attempted to execute and throws the exception. This may or may not involve stack crawl (which is very expensive) depending on JIT ability to prove if the stack would be unused. Nulls should be avoided, all fields should be initialized, etc. Nulls are great for =very= high performance code as null checks are virtually free.
- arethuza 8y agoI remember seeing sample code from WebLogic that returned values from methods using exceptions. Mind you this was in documentation rather than in production code - but hardly a good example to follow!
- int_19h 8y agoI've seen a horrifying adaptation of this pattern in C++, where a piece of code was using catch(...) to detect dereferencing an invalid (not even necessarily null, just an object that's gone!) pointer.
- lultimouomo 8y agoThat's strange, as dereferencing an invalid pointer in C++ will not cause anything to be thrown. In the best case you immediately get a segfault; if you're unlucky the code just goes on reading random data from memory and crashing some time after that.
- marshray 8y agohttps://docs.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model?view=vs-2017 https://docs.microsoft.com/en-us/cpp/build/reference/eh-exce...
- int_19h 8y agoThe standard is U.B., so throwing is a valid response. On Win32, a segfault / access violation - and similar low-level errors, like division by zero - is represented as something called "structured exception". These have a standard OS ABI such that they can be caught, and stack can be unwound, across different languages. In MSVC, normally, they are not treated as C++ exceptions for the purpose of catching them, although it will still participate in stack unwinding (if something else below is catching them). However, there is an opt-in compiler switch that does make them look like C++ exceptions in a sense that catch(...) will catch them. It's not something you'll see in most code written in the past 15 years or so, for obvious reasons.