Suppose I have 10 lines of code. Any line maybe throw a NullPointerException. I don't want to care about these exceptions. If a line throws the exceptions, I want the executor jump to next line and go forward. Could I do this on Java? if yes, please give me some sample code.
UPDATE: (add sample source for more clear question)
first.setText(prize.first);
second.setText(prize.second);
third.setText(prize.third);
fourth.setText(prize.fourth);
fifth.setText(prize.fifth);
sixth.setText(prize.sixth);
seventh.setText(prize.seventh);
eighth.setText(prize.eighth);
Suppose I have 8 lines of code above. What I want is: if the line 4 (or 5, 6,...) throws an exception, all other lines of code works normally. Of course I can use try...catch to catch the exceptions line by line. But this way make my source very complex.
This is impossible. If you think about it for a while, you'll realize that that is also a nonsense. Take this code for example:
String s = getSomeString(); // assigns null
int length = s.length; // throws NPE
if (length > 10) { // what would you do here?? length is un-initialized
domeSomething();
}
Edit
Now that you've updated you question with a code snippet, there are two general approaches to deal with nulls:
1. Disallow them where they aren't supposed to be
In your code snippet, you've provided a list of EditTexts, where any o them might be null. Well, in my opinion if you have an Activity in Android which should have some Views, then it is a programming error if any of them is null for whatever reason. An activity without some of its views can't work properly, so throwing a NPE and exiting the application is a perfectly sensible thing to do.
The NPE tells you "hey, you've made a mistake and you have to fix it". Until then, it is not safe for the app in an unpredicted state to continue execution, because no one knows what can happen, what data can become corrupted.
2. Allow them where they make sense, and provide null-checks
There are some places where you can have variables whose value can be empty. There are several approaches how to express an empty value and null is the most obvious one.
In that case, you can't just ignore the possibilty of a NPE and you have to do some null-checks. But again, a NPE is not your enemy. It will tell you that you've forgotten to account for all the possible situations that you should have.
Of course, repeated null checks make the code cluttered and noisy, so you can create some methods that generalize the null checks for you. I could not come up with a sensible example, so take this method only for illustration:
public void clearEditTexts(EditText... editTexts) {
for (EditText e : editTexts) {
if (e != null) {
e.setText("");
}
}
}
This method clears the contents of all the passed EditTexts. Any of them can be null, but this method does these null-checks internally, so you don't have to do it manually for each of them.
This question is also a very good reading about handling nulls:
Avoiding != null statements
This is not possible. If your variables can be null you will just have to check for that, or prevent them from being null. Very rarely it can be useful to create a dummy object implementation whose overridden methods do nothing, so it can be used in place of a valid object instead of null.
The fact that a variable is null is notable, and should not be ignored. Therefore, you'd want something like this:
...
if(first != null && prize.first != null)
{
first.setText(prize.first);
}
...
If, for some reason, you absolutely need to throw NPEs, you would need to surround each line with its own try/catch; there's no way to automatically catch exceptions and have it advance to the next line. It's not, however, recommended to do this.
...
try
{
first.setText(prize.first);
}
catch(NullPointerException e)
{
}
try
{
second.setText(prize.second);
}
catch(NullPointerException e)
{
}
...
No, you cant and you should care, they try to tell you whats wrong.
NullPointerException is a runtime (unchecked) exception and Java not reccomand to catch unchecked exceptions. You should have a solution to prevent it.
Related
This question is similar to this one, but the focus is somewhat different
I have a function that loads a file on disk in a try catch block. Because the file is crucial to the program, it will terminate if it fails to load the file:
String loadSuperImportantFile() {
try {
// ... file loading code ...
assert fileContent != null;
return fileContent;
} catch(IOException ex) {
System.err.println("Failed to load super important file. Please check path.");
System.exit(Codes.FAIL); // terminate the program
}
return null; // statement is unreachable
}
IntelliJ IDEA does not recognize that it is impossible for this function to return null. Because of this, I get warnings whenever I use the return string:
foo(loadSuperImportantFile()); // WARNING: Argument "loadSuperImportantFile()" might be null.
From reading the question I linked up above, I believe it may be possible to use Method Contracts to tell IntelliJ that the method cannot return null. I tried using the #Contract("null -> fail") decorator, but the warnings did not disappear.
Does anyone have an ideas on how to make the warnings disappear in the method itself, using a Method Contract or something similar, rather than null checking externally?
System.exit(Codes.FAIL); is not a terminating statement in Java (like return or throw).
In some wired cases, you could imagine, that it is possible to override exit method (or mock it), in such a way it doesn't terminate the application. Then this null would be returned.
For a concise and robust application, if you want to terminate the application, throw an Exception that would propagate up. Especially, if you want to terminate your application because an error occurred (invalid path). It would be even more pragmatic, to let the application die on it's own. Why do you have to call System.exit();?
PS: You can also see the answers of #Stephen C or #user31601, and that would surely fix your problem with method returning null (because it uses flow control statement - throw), but I wouldn't suggest that option. In my opinion, it would be better to design a better structue, one that is concise, and doesn't let such situation occur - in opposite to allow it to happen, and then throw AssertionException when it does.
PS2: You could also add #NotNull like #yole suggested, but again - instead of reacting to thing that shouldn't happen - just don't let it happen. And throw (for example) throw new InvalidPathException();.
My suggestion:
String loadSuperImportantFile() {
try {
return fileContent;
} catch(IOException ex) {
throw new ImportantFileMissingException("Failed to load super important file. Please check path.");
}
}
class ImportantFileMissingException extends RuntimeException {}
IntelliJ IDEA does not recognize that it is impossible for this function to return null.
IntelliJ is simply following the standard Java reachability rules. These say that the return null; statement is reachable.
Does anyone have an ideas on how to make the warnings disappear in the method itself.
You could replace the last statement with this:
throw new AssertionError("unreachable statement executed");
Or better still, put it after the System.exit(...) call.
Any unchecked exception would do, but to my mind an AssertionError is the strongest indication that something totally wrong has happened. Note that you need to explicitly throw the exception. Using an assert is not sufficient to avoid the need for a return ... since assertion checking can be turned off.
The runtime cost of a throw statement that is never executed is minimal to zero.
Another idea is to return a dummy non-null value. In this example, an empty string would do.
The problem with annotating the method as #NotNull is that a static code analyzer (using the same incomplete logic as IntelliJ) may flag that the method does return null. If you can suppress that warning, there is also the possibility that some framework might insert a runtime check for null ... which 1) serves no purpose and 2) maybe can't be optimized away.
Unfortunately, there is no practical way to tag System.exit with an annotation that says "this statement never returns". Why? Because it is a standard method, and you can't change it ... without hacking the class libraries and (potentially) breaking portability.
The best you can do (I think) to fix the problem would be to develop and submit a patch to the Intellij maintainers. One that "understands" the special behavior of System.exit.
Finally, it is generally speaking a bad idea for a library method to call System.exit in a method like in your example. A better approach is to throw a custom exception which you catch at / near the base of the call stack ... on the application's controlling thread. That way, you can have all of the code and logic that governs (controlled) application exit in the same place.
A subsidiary method should not be deciding about the "fate" of the overall application.
Why don't you just add a terminating statement to the end of catch block? It will never be reached, so all it should do is help the compiler infer that the final return statement isn't necessary.
For example:
String loadSuperImportantFile() {
try {
// ... file loading code ...
assert fileContent != null;
return fileContent;
} catch(IOException ex) {
System.err.println("Failed to load super important file. Please check path.");
System.exit(Codes.FAIL); // terminate the program
throw new AssertionError("Unreachable");
}
}
Simply annotate the method as #NotNull. The #Contract annotation you've tried to apply says that the method will fail if you pass null to it as a parameter, which does not make sense because it does not have any parameters.
You could also return an Optional<String> instead of a String.
This way, you could avoid returning null and return an Optional.empty() instead to avoid null checking and possible NullPointerException.
See: https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html
When reading JDK source code, I find it common that the author will check the parameters if they are null and then throw new NullPointerException() manually.
Why do they do it? I think there's no need to do so since it will throw new NullPointerException() when it calls any method. (Here is some source code of HashMap, for instance :)
public V computeIfPresent(K key,
BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
if (remappingFunction == null)
throw new NullPointerException();
Node<K,V> e; V oldValue;
int hash = hash(key);
if ((e = getNode(hash, key)) != null &&
(oldValue = e.value) != null) {
V v = remappingFunction.apply(key, oldValue);
if (v != null) {
e.value = v;
afterNodeAccess(e);
return v;
}
else
removeNode(hash, key, null, false, true);
}
return null;
}
There are a number of reasons that come to mind, several being closely related:
Fail-fast: If it's going to fail, best to fail sooner rather than later. This allows problems to be caught closer to their source, making them easier to identify and recover from. It also avoids wasting CPU cycles on code that's bound to fail.
Intent: Throwing the exception explicitly makes it clear to maintainers that the error is there purposely and the author was aware of the consequences.
Consistency: If the error were allowed to happen naturally, it might not occur in every scenario. If no mapping is found, for example, remappingFunction would never be used and the exception wouldn't be thrown. Validating input in advance allows for more deterministic behavior and clearer documentation.
Stability: Code evolves over time. Code that encounters an exception naturally might, after a bit of refactoring, cease to do so, or do so under different circumstances. Throwing it explicitly makes it less likely for behavior to change inadvertently.
It is for clarity, consistency, and to prevent extra, unnecessary work from being performed.
Consider what would happen if there wasn't a guard clause at the top of the method. It would always call hash(key) and getNode(hash, key) even when null had been passed in for the remappingFunction before the NPE was thrown.
Even worse, if the if condition is false then we take the else branch, which doesn't use the remappingFunction at all, which means the method doesn't always throw NPE when a null is passed; whether it does depends on the state of the map.
Both scenarios are bad. If null is not a valid value for remappingFunction the method should consistently throw an exception regardless of the internal state of the object at the time of the call, and it should do so without doing unnecessary work that is pointless given that it is just going to throw. Finally, it is a good principle of clean, clear code to have the guard right up front so that anyone reviewing the source code can readily see that it will do so.
Even if the exception were currently thrown by every branch of code, it is possible that a future revision of the code would change that. Performing the check at the beginning ensures it will definitely be performed.
In addition to the reasons listed by #shmosel's excellent answer ...
Performance: There may be / have been performance benefits (on some JVMs) to throwing the NPE explicitly rather than letting the JVM do it.
It depends on the strategy that the Java interpreter and JIT compiler take to detecting the dereferencing of null pointers. One strategy is to not test for null, but instead trap the SIGSEGV that happens when an instruction tries to access address 0. This is the fastest approach in the case where the reference is always valid, but it is expensive in the NPE case.
An explicit test for null in the code would avoid the SIGSEGV performance hit in a scenario where NPEs were frequent.
(I doubt that this would be a worthwhile micro-optimization in a modern JVM, but it could have been in the past.)
Compatibility: The likely reason that there is no message in the exception is for compatibility with NPEs that are thrown by the JVM itself. In a compliant Java implementation, an NPE thrown by the JVM has a null message. (Android Java is different.)
Apart from what other people have pointed out, it's worth noting the role of convention here. In C#, for example, you also have the same convention of explicitly raising an exception in cases like this, but it's specifically an ArgumentNullException, which is somewhat more specific. (The C# convention is that NullReferenceException always represents a bug of some kind - quite simply, it shouldn't ever happen in production code; granted, ArgumentNullException usually does, too, but it could be a bug more along the line of "you don't understand how to use the library correctly" kind of bug).
So, basically, in C# NullReferenceException means that your program actually tried to use it, whereas ArgumentNullException it means that it recognized that the value was wrong and it didn't even bother to try to use it. The implications can actually be different (depending on the circumstances) because ArgumentNullException means that the method in question didn't have side effects yet (since it failed the method preconditions).
Incidentally, if you're raising something like ArgumentNullException or IllegalArgumentException, that's part of the point of doing the check: you want a different exception than you'd "normally" get.
Either way, explicitly raising the exception reinforces the good practice of being explicit about your method's pre-conditions and expected arguments, which makes the code easier to read, use, and maintain. If you didn't explicitly check for null, I don't know if it's because you thought that no one would ever pass a null argument, you're counting it to throw the exception anyway, or you just forgot to check for that.
It is so you will get the exception as soon as you perpetrate the error, rather than later on when you're using the map and won't understand why it happened.
It turns a seemingly erratic error condition into a clear contract violation: The function has some preconditions for working correctly, so it checks them beforehand, enforcing them to be met.
The effect is, that you won't have to debug computeIfPresent() when you get the exception out of it. Once you see that the exception comes from the precondition check, you know that you called the function with an illegal argument. If the check were not there, you would need to exclude the possibility that there is some bug within computeIfPresent() itself that leads to the exception being thrown.
Obviously, throwing the generic NullPointerException is a really bad choice, as it does not signal a contract violation in and of itself. IllegalArgumentException would be a better choice.
Sidenote:
I don't know whether Java allows this (I doubt it), but C/C++ programmers use an assert() in this case, which is significantly better for debugging: It tells the program to crash immediately and as hard as possible should the provided condition evaluate to false. So, if you ran
void MyClass_foo(MyClass* me, int (*someFunction)(int)) {
assert(me);
assert(someFunction);
...
}
under a debugger, and something passed NULL into either argument, the program would stop right at the line telling which argument was NULL, and you would be able to examine all local variables of the entire call stack at leisure.
It's because it's possible for it not to happen naturally. Let's see piece of code like this:
bool isUserAMoron(User user) {
Connection c = UnstableDatabase.getConnection();
if (user.name == "Moron") {
// In this case we don't need to connect to DB
return true;
} else {
return c.makeMoronishCheck(user.id);
}
}
(of course there is numerous problems in this sample about code quality. Sorry to lazy to imagine perfect sample)
Situation when c will not be actually used and NullPointerException will not be thrown even if c == null is possible.
In more complicated situations it's becomes very non-easy to hunt down such cases. This is why general check like if (c == null) throw new NullPointerException() is better.
It is intentional to protect further damage, or to getting into inconsistent state.
Apart from all other excellent answers here, I'd also like to add a few cases.
You can add a message if you create your own exception
If you throw your own NullPointerException you can add a message (which you definitely should!)
The default message is a null from new NullPointerException() and all methods that use it, for instance Objects.requireNonNull. If you print that null it can even translate to an empty string...
A bit short and uninformative...
The stack trace will give a lot of information, but for the user to know what was null they have to dig up the code and look at the exact row.
Now imagine that NPE being wrapped and sent over the net, e.g. as a message in a web service error, perhaps between different departments or even organizations. Worst case scenario, no one may figure out what null stands for...
Chained method calls will keep you guessing
An exception will only tell you on what row the exception occurred. Consider the following row:
repository.getService(someObject.someMethod());
If you get an NPE and it points at this row, which one of repository and someObject was null?
Instead, checking these variables when you get them will at least point to a row where they are hopefully the only variable being handled. And, as mentioned before, even better if your error message contains the name of the variable or similar.
Errors when processing lots of input should give identifying information
Imagine that your program is processing an input file with thousands of rows and suddenly there's a NullPointerException. You look at the place and realize some input was incorrect... what input? You'll need more information about the row number, perhaps the column or even the whole row text to understand what row in that file needs fixing.
I know that NPE is not recommended to be caught, however the NPE is in a method whose return value is a boolean based on the variable where the NPE comes from.
Code is something like this:
public static boolean isStale() {
return a.get(); //a==null causing NPE
}
In my case, I don't really know what to return without the info of a.
What should I do? What kind of exception should I throw, if any?
Edit:
1. returning true or false will be inaccurate because the result really depends on the info inside a.
a is acctually from a service call client.getA()
There is no reason why you should prevent your code from throwing exceptions. Just consider your case : you say yourself that the behaviour of your method is not defined in the case a == null, so why should you handle it ? It will only lead to weird behaviours and your users might be surprised that their code failed or produce unexpected results somewhere whereas their calls into your API went fine.
Exceptions are specially designed to address this kind of things, so make good use of it. You can either throw a new, custom exception to add some API-specific semantic, or let the NPE be propagated to the caller.
For example :
public static boolean isStale() {
if (a == null) throw new IllegalStateException("a should not be null");
return a.get();
}
However, it is more likely that you should do that in a constructor (because I assume a is an attribute). In a constructor, I would opt for IllegalArgumentException.
First you need to ask yourself: Is it normal for a to ever be null?
If yes, then throwing an exception is rarely a good idea. Exceptions should really only be thrown when something unexpected occurs. It then really is up to you to decide what this means for your program. Does it make sense to return some default value in this case?
return a == null ? false : a.get(); // return false as a default value?
If no (more likely):
... then ask the following question: Why am I getting a null value?
If it's because you coded a bug: then you don't need to do anything. Just let it throw a NullPointerException. There really is no point in catching the exception and pretending everything is alright, if clearly, a basic invariant in your program has been broken. Better to let it throw the exception early and focus your energies on understanding and fixing the bug asap. Trying to handle the exception will only cause your program to fail at some other more unexpected point in time, and will become that much harder to debug.
If, on the other hand, it's because of some external entity feeding you bad data over which you really have no control: then this could be a good case for throwing a custom exception that can be used to provide a more meaningful error message to either the user or the developer. But even in this case, it's probably a better idea to have a validated for a null value more "upstream" and have it throw an exception as early as possible. It doesn't feel like it should be part of the isStale() method's contract to worry about the correctness of a's value.
Interesting reading, geared towards C#, but the principles apply just as well to Java: Vexing exceptions.
This depends on what isStale() determines. You can try/catch this method and catch the NullPointerException. I don't believe this violates best practices if you really have no way to handle a being null. You could also instantiate a new a if a is null, or throw your own Exception.
There's no need to throw any Exception just make sure a isn't null before using it, use a simple conditional statement:
public static boolean isStale() {
a!=null ? return a.get() : return false;
}
In the case where returning false will be irrelevant, you can just change the return type of your method to String and return a warning or any other significant message :
public static String isStale() {
a!=null ? return a.get().toString() : return "NULL";
}
Take a look at this: Best approach to converting Boolean object to string in java
We're having trouble tracking down Null Pointer Exceptions in our code using Eclipse and I was wondering if Eclipse offered any help in this area. What ways does Eclipse offer to easily track down Null Pointer Exceptions?
To illustrate, here is a typical code example that is throwing an NPE:
if (myObject.getDimensionMap().get(keyValue.getConcept()).isMeasureDimension()) {
Unless I'm mistaken there are 5 possibilities where an object could be null:
myObject could be null
myObject.getDimensionMap could be null
keyValue could be null
keyValue.getConcept could be null
myObject.getDimensionMap().get(keyValue.getConcept) could be null
Avoiding the argument of changing the code so each statement is on a different line, does Eclipse offer any way of helping to find the NPE without having to step into each statement? Bear in mind that it took the dev team quite a while to even get to this statement let alone find out which one of the elements was null (it was the getDimensionMap().get ).
Update:
It took so long to find the actual cause of the NPE because the offending code was buried in a deep call hierarchy, where the outer layer has a catch for all exceptions. The reason for this is so that the exceptions can then be rendered in a more attractive format and displayed to the user. So the code is like
try {
doSomething
...
callSomething
callSomethingElse
...
offending if test which throws the NPE
...
} catch (Exception e) {
// Format exception and pass back to client
}
Of course, the user never want to see the phrase NullPointerException....
Thanks.
From Eclipse, Run/Add java Exception Breakpoint.
Select NullPointerException. Ensure 'suspend on caught exception' is ticked.
Only downside is it will trigger on any code that intentionally raises and catches NPEs internally.
Effective java recommends that we shouldn't catch NullPointerException.
Is it always right?
In many cases of catching NullPointerException, catch body only calls printStackTrace().
If I don't catch NullPointerException and call printStackTrace(), how I can check the place where the exception occurred?
And also if I catch NullPointerException and the catch body is empty, we cannot get any stack information at that time, can we?
UPDATE
I analyzed statistics of catching RuntimeException in google android source, AOSP4.2.2_r1.2.
There are 249 RuntimeException catchings and followings are statistics of catch-body.
42%: throw it again as other Exceptions (RuntimeException: 33%, others: 8%)
32%: just return null or 0/false/true or other default values
14%: just call log or printstacktrace
5%: just comment like "// Fall through.", "// ignore, not a valid type.", "// system process dead", "// do nothing"
2%: empty body
3%: display error messages or send fail codes (ex. network service discovery failed: replyToMessage(msg, NsdManager.STOP_DISCOVERY_FAILED, NsdManager.FAILURE_INTERNAL_ERROR); )
3%: intialize or reset related variables.
In almost cases, dalvik and external handle NPE by throwing other Exceptions.
But frameworks usually handle by returning null or other values.
Do you think that throwing other Exceptions in catch-body is not bad or good handling?
If NPE occured in higher levels(ex. applications) and the developer confirms the exception is not critical because the app is fully independent, can I accept for our developer to ignore the NPE by catching?
and one more thing,
Can I conclude that google android framework source code may be some unstable in aspects of RuntimeException?
Effective java recommend that we shouldn't catch NullPointerException. Is it always right?
In nearly all cases it is correct.
NullPointerException is usually a result of a bug; i.e. your application encountered a null object reference in a situation where it was not anticipated, and then attempted to use it. In this scenario, since you (the programmer) did not anticipate the null, it is next to impossible to know whether it is safe to attempt to recover, and / or to know what "remediation" might be required. So the best thing to do is to let the NPE propagate to the base level, and then treat it as a generic bug. (In "network service" applications, it may be appropriate to return a "service error" response, and attempt to continue.)
The other scenario is where you (the programmer) anticipate that a null might be delivered. In this case, the best strategy is (nearly always) to explicitly test for the null before you attempt to use it, thereby avoiding the NPE ... and the need to handle it. There are two reasons for this:
Exception handling is typically expensive. Indeed it can be many orders of magnitude more expensive than testing for a null.
If you allow the expected NPE to happen and then catch it, you are liable to also catch other unexpected NPEs ... and handle them incorrectly.
Note that I qualified the above by saying "nearly always". It is theoretically possible to have a scenario where explicit tests for null clutter up your code so much that it is at least worth considering allowing the NPE to happen. However, there is still the possibility of unexpected NPEs as well ... depending on the code. So this approach is always potentially fragile.
(FWIW - I've never encountered a real case where this would be a good idea ...)
In many cases of catching NullPointerException, catch body only calls printStackTrace().
That is probably bad code. Doing nothing is rarely the correct way to recover from an NPE.
If I don't catch NullPointerException and call printStackTrace(), how I can check the place where the exception occurred?
You let the NPE propagate to the base level. There you catch and print (or log) a stacktrace for all unhandled exceptions, and then either bail out or attempt to recover ... if that is feasible.
And also if I catch NullPointerException and the catch body is empty, we cannot get any stack information at that time, can we?
Never, ever do this! It is called "squashing" and is dangerous. (Especially since, as I explained above, the NPE may be due to something that you / your code did not anticipate.)
And no, if you do this, you can't get the stack trace. It is gone.
FOLLOWUP
I don't place much trust / faith on some general strategies for "avoiding NPEs"1. For instance stuff like this:
return (someObject != null) ? someObject.toString() : "";
always make me suspicious that the programmer is not thinking about the problem. Why was someObject a null in the first place?
A NPE is caused by having a null in place where you don't expect it. As such, NPEs are usually symptoms of a problem rather than the actual problem itself. To my mind, NPEs are not something to be avoided. Rather, you should be using the NPEs to find and fix the root cause of the unexpected null. Code like the above that avoids the NPE gets in the way of that goal.
So I prefer / recommend strategies for avoiding null values in unexpected places.
Make sure that every reference field is gets initialized to a non-null value ... unless null is a meaningful value.
Try to avoid having null as a meaningful value, especially if there is an alternative. For instance, an empty String, a zero length array, an empty collection, a distinguished instance that means "undefined" or whatever. Or, for Java 8 and later, use Optional.
Don't return null as an error or an indication of a special case. (Throw an exception or return a distinguished value.)
Check early for unanticipated null values (e.g. null arguments), and throw the NPE sooner rather than later.
In the few places where a null argument or result is legitimate, make sure that your javadocs document this clearly and explicitly. If there is no documentation, then the implication should be that null is not allowed and won't be returned.
And wherever you get an NPE, make sure that you find and fix the real source of the problem ... not just the specific statement that threw the exception.
1 - There is value in knowing about places in the standard Java APIs where null is used (or abused) as a return value. For instance, Class.getResourceAsStream(...) or HttpRequest.getParam(...). Those "advice for avoiding NPE" documents are useful in as much that they point out these traps.
NullPointerException typically occurs due to logical errors in our code. We can eliminate NullPointerException by avoiding unsafe operations. If any NullPointerException still happens, you can see it in StackTrace.
For example
if (Obj.getName("Sam")) {
// only executes if Obj != null
}
We can avoid NullPointerException as follows
if (Obj == null){
System.out.println("Null Obj, Can't proceed");
} else {
Obj.getName("Sam")
}
Generally It is recommend that one should not catch NullPointerException and let it be handled by JVM.
But it all depends,
Say for eg: if you have code like List<Student> listStudent = getAllStudent();
here getAllStudent() connects to DB and give you result, Here before doing any operation on list object you should check that
if(listStudent != null){
//do the task.
}else{
//Show Message like no student is there instead of catching NullPointerException
}
if you will not do, then chances are there that NullPointerException can occur if no data is there.
so better practice is to check for Nulls but not handle it like
try{
}catch(NullPointerException e){
}
You definetly should not use empty catch block without REALLY IMPORTANT reason. Usually there is no such reason.
Usually it's good either to check if variable is null or catch NPE and trow more appropriate reason. For example if a method getCar() returned null you may catch NPE on trying to call some method of the car, or check if the car is null and throw RuntimeException(but only if the situation is really exceptionable). Thus you make errors more abstract-binded and easier to understand.
When an exception is thrown, be it any exception, jvm looks for the closest handler(catch block). If it is not found in the current method, it looks for the handler in the calling code and so on. SO basically the entire calling stack is searched bottom-up to look for a catch block which can handle the said exception. If no handler is found jvm uses the default handler which calls the e.printStackTrace()
Now NullPointerException is a runtime exception, which basically points to some logical fallacy in the code. There are times when you may want to catch it. But as a thumbrule:
don't catch runtime exceptions, they generally point to logical errors
don't leave an empty catch block, you will lose the stacktrace and the exception if you catch it but do not act upon it.
don't just print the stacktrace to standard outout, instead log it somewhere for later analysis, if needed
The convention is to avoid catching any sort of runtime exception. The reason being: something horrible has gone wrong, and you as a developer should be keen on fixing it thirty minutes ago.
NullPointerException is, in fact, a subclass of RuntimeException. Like other classes that have a parent of RuntimeException, they are considered unchecked - so code compiles even if it's going to produce an NPE:
// This would appropriately return "false", if the order were reversed
// and something was empty.
public boolean doSomething(String something) {
String hello = null;
if(hello.equals(something)) {
System.out.println("Wow");
}
}
Explicitly catching any sort of runtime exception indicates that you expect horrible, bad things to happen over the course of the program, and you wish to gloss over that fact.
As for what goes in the body of the catch block...that's probably being automatically generated by your IDE. If you're not propagating the exception to the higher levels of your application, then you need to get useful context as to why your program blew up.
If you don't put anything in the catch block, it's silently ignored - which is bad.
Usually NullPointerException signifies a logical error in the API usage or exepcted value is missing. That's why it's recommended to to throw it back. However you can catch it. Practically
I will suggest you to catch when you want to give default values for
the passed null parameters.
For example :
You are expecting timeout value to be configurable and you expect that user has to pass it. However user forgets to pass it. In this scenario you can catch the NPE and log a warning that you are using the default value for the parameter.
NullPointerException is a situation in code where you try to access/ modify an object which has not been initialized yet.
It essentially means that object reference variable is not pointing anywhere and refers to nothing or ‘null’.
Joshua bloch in effective java says that:
“Arguably, all erroneous method invocations boil down to an illegal
argument or illegal state, but other exceptions are standardly used
for certain kinds of illegal arguments and states. If a caller passes
null in some parameter for which null values are prohibited,
convention dictates that NullPointerException be thrown rather than
IllegalArgumentException.”
So, if you must allow NullPointerException in some places in you code then make sure you make them more informative then they usually are.
Read more about Effective NPE Handling from here:
http://marxsoftware.blogspot.in/2009/04/effective-java-nullpointerexception.html
http://howtodoinjava.com/2013/04/05/how-to-effectively-handle-nullpointerexception-in-java/
You dont have to actually do e.printstacktrace() all the time , you can specify your own body message using logger or System.out.println()
Robust, user centric code should try to catch such a 'FATAL ERROR' if there is anything ANYTHING at all you could do about it. You could retry the attempted function call. Perhaps this null exception is due to something transient. Something that really shouldn't throw an exception and should be coded better for the transient failure but, which, however should not deter the end user from getting what he wants, instead of abandoning what could be a lengthy stateful form input process, and only on the last, completely insignificant step, like entering the users's email preference or something does the null pointer error occur and trash the user's existing input.