Exception is your friend

In the mid-nineties, when I switched from programming under DOS to Windows, my mentor introduced me to the exception mechanism.
Since then, an opinion has taken root in my mind: a program falling with an exception is a bad program. All exceptions must be processed and terminated in the event of an emergency situation independently.
And this is quite true for a regular Windows application. After all, in the event of an application crashing, a user receives a vague error message and, as a result, a negative perception of an unstable application.
My opinion began to change after becoming acquainted with the tools for automatic exception handling (such as EurekaLog and peers).
And finally changed after becoming familiar with the Google Play report system.
This post is a cry from the heart against those thousands of examples that teach us to shove hasty checks into your code.

The reason for writing this post was a dialogue with a friend who asked for advice on the implementation of the interaction of NDK with Java code. I was shown the source code written on the basis of this manual .
Code calling questions:

jmethodID method = env->GetStaticMethodID(interfaceClass, "callBack", "(Ljava/lang/String;)V"); if(!method) { LOGE("callback_handler: failed to get method ID"); return; } env->CallStaticVoidMethod(interfaceClass, method, js); 

This is a classic example of code that looks right, but in fact only creates new problems.
Checking is needed here only in one case - if the callBack method is not required to exist and may be absent in the normal mode of the application.
Checks are needed when we check the results of the work of network modules or when we work with external files, etc.
That is, when an error may occur due to external factors. In this case, error checking is our direct responsibility.
The situation changes completely when the error is generated by our code and does not depend on external factors.
If callBack is described by us and must be present in the code, verification is not needed.

The check will only mask the error.

It is very important to understand that error masking is bad. Much worse than the fall of the application with the exception.
You can say that the message is displayed in the log and pops up during testing.
Well, great if pops up. And if not pops up? If the user leaves the non-working code, who will just silently ignore the call call callBack?
Your users will work with a program that does not perform the intended functionality. Well, if this is any trifle that does not seriously affect the operation of the application. But what if an important part of the code is hidden there, because of which all the user's work results turn out to be incorrect?
Remove the check and the first user who encounters a callBack call will receive the application crash. And you - an error report with a completed call stack. At a minimum, it will draw your attention to the problem. Yes, the user will be unhappy. But within five hours you will upload a new version to Google Play and thousands of users will not even know about this problem.
This is much better than a huge client base, working with the application with a time bomb.

Error checking is an important part of the application. Errors of various kinds occur constantly. There is not a single launch of any complex application that would occur without several errors. But it is necessary to separate regular errors from non-standard ones. Established errors are those errors that are permissible and whose effect is predictable. These errors need to be processed within the application and change the logic of work depending on the situation. In no case can abnormal errors be handled by standard checks. It is impossible to just take and shove a block of code in if with a NULL test. You should always clearly understand why the object has become NULL and what it threatens in the operation of your application.
')

So what to do with the checks?

You can not do anything. Just remove the check. In the above example, we know for sure that in the case of the lack of a method, an exception will be raised in the next step.
This option is acceptable, but not very good, because an exception call is outside of our code and we cannot guarantee that an exception will be thrown.
Therefore, in the ideal case, verification is necessary, but not with recording the error in the log, but with raising an exception to ensure that the execution of the code is stopped and the error report is sent.

Of course, I did not discover America for professionals who know firsthand how harmful the concealment of mistakes is.
This text is aimed at beginners who study programming from examples from the Internet ... And in the meantime, examples are full of meaningless and merciless checks ...