I went through this tutorial to learn about Firebase crash reporting. This is the code I've written to use it:
FirebaseApp.initializeApp(this);
try {
throw new FileNotFoundException();
} catch (FileNotFoundException ex) {
FirebaseCrash.logcat(Log.ERROR, TAG, "NPE caught");
String exception=ex.toString();
FirebaseCrash.report(ex);
}
In my Firebase console I can see my error. Everything is working perfect but I have one question. Is there any way to catch any exception wherever it occurs?
Firebase Crash Reporting will capture any Exception that does not get explicitly caught and crashes your app. You don't have to worry about that. Those are marked as Fatal exceptions in the dashboard. Exceptions you report are marked as non-fatal.
As a general rule, you should not try to suppress all exceptions, in order to prevent your app from crashing. Some exceptions indicate an unrecoverable situation or programming error, and your app process really should go away in order to prevent things from getting worse. Attempting to change this behavior could be worse for your users than seeing the Android crash dialog.
Related
I have a try block and a catch block where NullPointerExceptions are caught. However, Lint warns that a statement in the try block may cause a NullPointerException, even though the exception will be caught. Why doesn't lint recognise that I have handled the possibility of the exception?
I am using Android Studio 3. Thanks.
As written here,
Programs must not catch java.lang.NullPointerException. A NullPointerException exception thrown at runtime indicates the existence of an underlying null pointer dereference that must be fixed in the application code. Handling the underlying null pointer dereference by catching the NullPointerException rather than fixing the underlying problem is inappropriate for several reasons. First, catching NullPointerException adds significantly more performance overhead than simply adding the necessary null checks [Bloch 2008]. Second, when multiple expressions in a try block are capable of throwing a NullPointerException, it is difficult or impossible to determine which expression is responsible for the exception because the NullPointerException catch block handles any NullPointerException thrown from any location in the try block. Third, programs rarely remain in an expected and usable state after a NullPointerException has been thrown. Attempts to continue execution after first catching and logging (or worse, suppressing) the exception rarely succeed.
Likewise, programs must not catch RuntimeException, Exception, or Throwable. Few, if any, methods are capable of handling all possible runtime exceptions. When a method catches RuntimeException, it may receive exceptions unanticipated by the designer, including NullPointerException and ArrayIndexOutOfBoundsException. Many catch clauses simply log or ignore the enclosed exceptional condition and attempt to resume normal execution; this practice often violates ERR00-J. Do not suppress or ignore checked exceptions. Runtime exceptions often indicate bugs in the program that should be fixed by the developer and often cause control flow vulnerabilities.
So, it appears like intentional behavior when Android Studio "ignores" NullPointerException catch blocks, and you should not be catching NullPointerException, instead just check for null.
See also this question.
The linter's job is to warn you of code that could be a problem. One of the built-in rules checks for dereferences that could cause NullPointerExceptions; it doesn't then check to see if this exception is caught.
However, I'm left wondering why you catch (NullPointerException e) instead of simply checking for null values and then proactively handling them.
I have a simple question. As we know, there are many places in the Android code where SecurityException is thrown for reasons. Is that reasonable that we catch the SecurityException and handle it but not let it crash the application?
If you catch every runtime exceptions, your application may not crash but it may not behave correctly as well. It might even crash at other points as well. The correct way is to handle those security failures. If you're handling a third-party API that can throw those security exception and it is not clear when those exceptions are thrown, then you may catch those exceptions. It is still better to understand why such situations occur - such as missing permissions, not having the required signature, etc.
I'm wondering if there is anyway to handle an application crash. By that, I mean if we can detect a crash and when it occurs save some data, because I need to save some values into a SharedPreference if the application crashes.
Is this possible?
Yes there is an open-source project for reporting or handling the crash report. try this link
ACRA
You Can Use Try...Catch...finally block to Catch Exception and when Exception occurs finally block content definitely works even exception handled or not.
I have an app that is running pretty stably (no more crashes actually), but as everybody knows your program crashes as soon as it gets in the hands of somebody else :D
What I would like is to find a(all) the place(s) where I can put a try{}catch(){} to be able catch and control what happens when the app crashes unexpectedly (display a better message, send log, possible recovery...)
I know its surely not that simple but still it would be good if there was a way to catch most of them.
(for example there is a small bug in GLSurfaceView that when it is being closed causes sometimes to crash because of an EGL swap buffer)
any ideas?
You should take a look at this article: http://stuffthathappens.com/blog/2007/10/07/programmers-notebook-uncaught-exception-handlers/
But be careful when using this, you might mask errors in your application and if you resort to this to just pretend your app is working, you're doing it wrong :)
Here's a really lazy way to catch any given exception:
try {
//do some stuff here
} catch (Throwable e) {
//handle exception here
}
This is useful if you have no idea what's going to be thrown. Consequently, it's not going to be very helpful for any kind of recovery. This is something I wouldn't use beyond the testing period of development.
I have some required try/catch statements in my application that in my testing never get called. I have sent them up with:
Log.e("messaage", e.toString());
for my debugging and now that I'm ready to release I am not sure if I should take that out or not. I see in android market you can get error/crash reports and while I do not expect my app to catch any errors, I would like to know if that happens and wondering if I need specific syntax for that. My question is what should I do in the catch statement for these errors? I'm already handling the error from a user standpoint...
Thanks!
IMHO logging is not really necessary, but sooner or later you will catch something. Acra may be of interest to you, if you want to be notified of these occasions.