4 ms·
Nothing wrong with null pointer exceptions - they are specific checks to see if the pointer is valid and are a good thing. If you see one, it means the programm
by RyanZAG 13y ago
Nothing wrong with null pointer exceptions - they are specific checks to see if the pointer is valid and are a good thing. If you see one, it means the programmer made a mistake and the runtime caught it for him.
There are also tools to help with it in the form of @NotNull, @Nullable, etc.
It's a completely different issue compared to actually accessing memory in an undefined way as you can in C. The bounds check you are replying to is manually creating something like that exception through the use of abort() while in java it is done always at the cost of some performance in exchange for safety.
- iopq 13y agoConsider the following: some languages don't have null. When you need nullable what you really want is an Option/Maybe type. No null pointer exceptions, ever! It just won't compile until you fix the bug.
- TheLoneWolfling 13y agoOr, more generally, I think languages should have union and intersection types - "(IFoo && IBar) || (IBaz)", etc. (I also think languages should have arbitrary Boolean expressions as types, where the compiler emits a warning and a runtime check if the compiler cannot prove either if the condition will be always met or it won't be always met, but that is another matter.) Null is just a built-in final/sealed type(enum?) with a single value and no operations defined, like boolean is a type(enum?) with two values. That, combined with proper type inference, would alleviate a large chunk of the boilerplate associated with statically typed languages in general, and Java in particular. (For how much Java is pushed as moving errors to compile time, there are an awful lot of things that fail only at run time that could be checked at compile time...) Same thing with checked exceptions. A checked exception is really just an option - return foo or failure.
- bad_user 13y agoEven when Java fails at runtime, because it forces garbage collection for memory management, buffer overflows and dangling pointers can't really happen - yes, if you're not careful, the process can still have unexpected behavior, or it might crash. Actually, the Heartbleed bug wouldn't have been such an issue if OpenSSL wouldn't use its own wrapper around malloc/free (at the very least, the malloc/free underneath would be a variable in that equation), e.g. http://article.gmane.org/gmane.os.openbsd.misc/211963 http://article.gmane.org/gmane.os.openbsd.misc/211963 So while I love strong and static type systems, the issue at play here is memory safety - the very reason for why people still use C/C++ is the same reason for why Heartbleed happened.
- TheLoneWolfling 13y agoYou're assuming that the JVM is secure. But yes, good point. Although I'd argue that a truly strong type system should also catch problems with pointers. The compiler should try to prove that any pointer access/arithmetic can or cannot cause undefined behavior - if it could cause undefined behavior, emit a compiler error, if it cannot prove that it won't cause undefined behavior, emit a warning and insert a runtime check. (Still have the underlying "unsafe" functions. But group them into part of the standard library as an "unsafe" package.)
- iopq 13y agoThat's what Rust does. Its type system prevents all memory and concurrency errors. But to be able to have a self-hosting compiler (and to be able to write an OS in it) there's also `unsafe` blocks.
- RyanZAG 13y agoIf you use @NotNull etc in Java, then it also won't compile until you fix the bug.