Capturing NullPointerException is bad practice?

5

I've been messing around with security issues and vulnerabilities lately, and in my research I came across an article that intrigued me.

According to OWASP :

  

Description   It is generally bad practice to catch   NullPointerException.

     

Programmers typically catch NullPointerException under three   circumstances:

     

1 - The program contains a null pointer dereference. Catching the   resulting exception was easier than fixing the underlying problem.

     

2 - The   program explicitly throws a NullPointerException to signal an error   condition.

     

3 -The code is part of a harness test that supplies unexpected   input to the classes under test. Of these three circumstances, only   the last is acceptable.

That is, according to this text, the only acceptable situation for capturing NullPointerException is in test cases, where the input may be something unexpected.

Why is not it a good idea to capture NullPointerException ?

Since it is not a good idea, how should I proceed if this exception is plausible within a scope?

How can NullPointerException be a threat to my system?

    
asked by anonymous 16.03.2017 / 13:47

2 answers

5

In general, yes, this is usually considered a programming error. If there is an expectation that the one information can be null, test it before accessing it. This is the only acceptable practice in almost every situation. I would say in all normality, but I am being cautious because it may have some useful situation. Exceptions are due to testing or solving a problem of something that you use and casts the exception wrongly. For me this is not even acceptable, if something is so bad, or fix it or switch vendor because that is serious.

Do you think it's plausible? have to demonstrate why it is. It's probably an evaluation error.

If there is this programming problem there is something wrong with the code, or the programmer has no idea what he is doing. This alone is a danger. I do not see a direct security problem, but maybe they sort it by the indirect effect. For example, if the plagiarism breaks down it may be that it has been poorly done elsewhere and leave something open that creates the vulnerability. The problem is not from NPE but from it to allow another failure to happen.

On the other hand, a general exception at some point in the application output should catch all exceptions, even the programming exceptions, to handle standard output, since it exposes internal application data that can be used to exploit some vulnerability. Note that this is not to treat NPE but to treat what can not be treated, only "makeup". Ideally there should be no programming errors in production.

In any case, just as good practices are bad, bad practices as well. If someone says something is bad then why not, otherwise if you can not determine for yourself or another source, disregard the claim. In this case until you find out why not treat it as a security problem but rather just programming.

if (objeto != null) {
    //faz o que tem que fazer
}

If you can, and you should do this before you have the exception, why will you let it happen to treat it? It does not make sense.

Some useful questions:

16.03.2017 / 14:02
2

There are two main types of exception: checkable and non-checkable. Checks (Exception) are those that Java forces you to handle because the user must be able to recover from the problem. Non-checkables (Runtime) are those that leave the state of the system unrecoverable and therefore do not need to be addressed. Nullpointer in Java is an uncheckable exception because if it were verifiable almost every method would have to throw this exception. This does not mean that it does not need to be treated, but it does not mean that you should always add treatment. The ideal is to treat specific exceptions and not so generic, since specific exceptions are provided and therefore allow the user to recover from the error. What is a threat to the system is to display the stacktrace of an exception not intended for the user. What needs to be done is to just log the exception to the server and display a neutral screen for the user who will not be able to recover from the unplanned exception.

    
16.03.2017 / 14:00