Hacker News Reader

Comment by idbentley | Hacker News Reader

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.

I'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.

That'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.

https://docs.microsoft.com/en-us/cpp/build/reference/eh-exce...

The 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.

I 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!

This 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.

Having a try..catch round such code would seem sensible but to rely on that over normal checking seems spectacularly horrible.

This is why Rust's '?' operator for error propagation is quite nice.

Or kotlin's '.?' operator for null propagation.

Or C#'s '?.' operator for null propagation.

Or Swift's ? And !

It’s a code smell if you are calling a method chain that long at all.

Cannot agree with you more. I personally hate chained expressions. Awful for debugging too.

It's only awful for debugging because the tools are awful.

The tools for Java are greate (try C++ if you disagree).

It's the code that is the problem here.

The 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.

Java debugging tools are beyond excellent for debugging such code (not that it should be written that way)

I 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.

This is largely not the case outside of the C-like languages that inherited nulls.

Long method chains with a strong type system or a functional (also called "fluent") style are extremely expressive and common in languages that obviate the need to handle null values at every member.

Regardless of safety guarantees (or lack thereof), a method chain that long indicates a lot of knowledge of the structure and hierarchy of the dependency. It makes refactoring/testing/mocking more difficult.

What does the length of the method chain have to with anything? Let's say I define an interface Foo.bar.xyz with method call, and I call the implementation foo.bar.xyzimpl.method()

Everything is just as testable and decoupled, it's just a different project structure.

Method chains have nothing to do with the things you stated.

It's usually a property chain, not a method chain - I don't think get...() is meaningfully a method in most cases, even if implemented as such.

I 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.

Reply on news.ycombinator.com