I would like to be able to determine, in case an exception occurs while the user is using my application, where exactly the exception took place. I'd like to do something similar ti printStackTrace() method. (So this is during build mode, not debug mode )
Currently I've put almost all my methods from all my classes inside a try-catch statement (each method has a try-catch statement which encompasses all it's instructions) and i can, at this point, display the "tree" or stack of methods if an exception occurs. But is there a way to determine either a line number of something to more precisely indicate where inside the method the exception occurred? Similar to what is displayed when you use printStackTrace().
I'm not really used with Exception handling, what is the best practice for doing this and can in be done?
EDIT
And one other thing. When i use printStackTrace() during build mode, where does it display the content, because Logcat isn't available? Can i retrieve that information and maybe do something with it?
OR
Even better, can i use getStackTrace() during build mode and convert the stuff there in String and maybe output it somewhere?
All the exceptions that are not handled by your code and make your app crash in release mode will appear in the android developper console, close to your app.
For this to work, you will need to retrace obfuscated stack traces.
About exception handling : I suggest you read this for instance. You are making a mistake about exception handling if you surround all your code by a try/catch block.
Exception handling is more subtile than that and is often influenced by design considerations (whether to treat exceptions locally or throw them back to the caller).
To sum up : in the core of your app : don't treat exception but throw them or let them be thrown, using the throws clause of your methods signatures. In the upper layers, closer to the UI, treat exceptions with try/catch and if an error occurs, make sure your app is in a stable state and display some usefull messages to users.
More details (but not that much) :
in the database layer : throw exception. You can still catch them to log them, but throw or rethrow them to tell caller that something went wrong.
in the business layer : catch them, make sure your business/domain model is in a stable state and recovers from the error, and throw them back to the caller.
in the UI layer : catch the exceptions and display some messages to users.
Related
I've encountered a situation where anything that runs in a coroutine (database queries, network requests or response processing) and fails at some point, simply crashes the app without any logs at all. Is it the expected behavior or do I have something misconfigured?
Here's a simple piece of code that reproduces the error.
Nothing changes with different Dispatchers.
This is the only output I'm getting, followed by app termination
And these are the dependencies I'm using, the latest version at the moment of writing.
It's also reproducing in a simple CLI app without the Android framework.
Edit: Just to make it clear. I'm not trying to see the Exceptions that I'm throwing. I'm trying to get some output when my app crashes because of an unknown reason.
Edit2: To add some clarity, here is another example of the situation without any "throw" statements.
Since the exception in happening inside the coroutine, it makes sense to find it there also. Just surround it with try/catch and you will see the magic:
GlobalScope.launch{
try{
print("Your printing message")
throw Exception("Message here")
}catch(exception: Exception){
exception.printStacktrace()
}
}
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 am trying to debug a Nativescript app for Android and I have noticed that it no longer prints Syntax errors with their corresponding line and col. numbers, not even console.log statements. How can I enable this feature again? The command I use to launch the app is tns run android. I am using Nativescript version 2.5.2. The VSCode plugin doesn't work either as it ignores any breakpoint I place, and also the console doesn't show any errors. What can I do?
Edit:
It appears that only console.error() statements get printed.
After tinkering a lot with different kinds of constructions and by researching more into how Nativescript relates to regular browser JS, I found out that the problem lies in the use of Promises, which in case of errors defer the execution to the catch() method, but unlike any other regular programming language, "unhandled" rejected results within promises won't raise any kind of exception; which means that, basically, for any promise you invoke in your code, you should have a chained catch() method call so you effectively catch any errors your promises might produce. This also applies to promises which involve navigation, where stuff gets a lot trickier: You might think the next view (say, view.js) will have a call stack on its own and produce an unhandled exception at code that's not even inside a promise in there, but that's not the case: An exception produced at view.js will get captured by the catch() method of the promise within which you started the navigation, and any subsequent promises must have their own catch() method calls because errors won't get bubbled up to the previous view. I can think of many other troublesome constructions but I hope the important bit stays clear: always chain a catch call on any and all promises.
I just learned about Log.wtf ("What a Terrible Failure" lol) and I'm wondering when I should use it.
What is the difference between calling Log.wtf with an exception and letting an exception go unhandled (crash)?
How does it affect crash reports in the Google Play Developer Console?
I usually throw an IllegalStateException for unexpected conditions. Should I consider calling Log.wtf instead?
Edit:
See also: Under what circumstances will Android's Log.wtf terminate my app?
What Log.wtf does is write the exception and its stack trace in the log, and only that. It neither catches nor throws exceptions. So
The difference is the exception is logged or not. The exception remains unhandled.
It doesn't affect crash reports.
If you wish to log it, go ahead. But you'll want to keep throwing IllegalStateException.
EDIT
I tried debugging and stepping into Log.wtf but no luck.
What I've found is pretty much what is answered in the linked question. It seems that in the "default terrible failure handling" Log.wtf creates an internal exception (TerribleFailure) which wraps any given exception. Then it calls RuntimeInit.wtf(). Its javadoc says:
Report a serious error in the current process. May or may not cause
the process to terminate (depends on system settings).
I guess the behavior of Log.wtf is up to the device manufacturer. My Sony C6503 doesn't seem to raise any exception or kill the process.
Some open source reference:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/util/Log.java
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/com/android/internal/os/RuntimeInit.java
Unhandled exceptions are not logged by default. Log.wtf may or may not crash the application. If you pass an exception to Log.wtf and it crashes, then you should get a stack trace similar to what you would get if the exception were not handled. After calling Log.wtf, you should (re)throw an exception if you want to ensure a crash (without catching it of course).
There may be specific use cases for Log.wtf, but if you are unsure, it's probably better to use Log.e instead.
Is there a way to catch, in one place, all "uncaught" exceptions and let the app continue?
I see I can use setUncaughtExceptionHandler to do some logging and whatever, but the app will still terminate. I want something where I can log an exception, tell the user his action failed, and let him keep going (try something else).
Thanks.
No. I'm not sure why you'd want it. Catch Exceptions from methods that are known to throw them, and test your code to avoid Exceptions such as NullPointerException. That's the way to write good code.
Sorry to revisit such an old thread but since there's no proper answer to it I felt obliged to provide a solution.
Add this to the activity that opens every time the app is used (MainActivity for example) -
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
public void uncaughtException(Thread paramThread, Throwable paramThrowable) {
Log.e("Exception"+Thread.currentThread().getStackTrace()[2],paramThrowable.getLocalizedMessage());
}
});
What it does is that it sets a default handler for uncaught exceptions and doesn't quit the app when one pops up. However, with great power comes great responsibility. I don't recommend you use this as a way to escape the responsibility of catching exceptions in your code (by using a try-catch for example). Test your code to make it as bug-free as possible before launch.