1

I am new to android development. In the overriden onCreate() method of my activity, I perform some operations. For ex. check if SharedPreference is already available and then route to other activity. How do I perform exception handling on this onCreate() method. Is it the right way to wrap the contents in a try catch and display the error dialog on exception?

If the exceptions are not handled properly, in my case the onCreate() method, the app crashes with message:

Unfortunately your application stopped working

On searching in the internet, I found that UncaughtExceptionHandler could be used to handle it. Any sample implementation and how to call it from all my activities would be helpful.

ישו אוהב אותך
  • 28,609
  • 11
  • 78
  • 96
user7161912
  • 31
  • 7

2 Answers2

0

With something like this you can catch a generic Exception in your onCreate() method:

@Override
protected void onCreate(Bundle arg0) {
    super.onCreate(arg0);
    try {
        // do whatever you need
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Exception catching can be used with many goals. An interesting one is to catch particular expected exceptions to fix some problems (for example setting a generic value into a variable otherwise null after occurring an error).

The general purpose however is to avoid that an error causes a problem or in the worst case a crash of your application. Depending oh what kind of software you are developing, a crash may represents a little problem (like in an Android app), a very big one (like in airplane's softwares or power plants' softwares).

We can identify two kind of exceptions.

The first type are those exceptions specific to definite problems. They have to be declared into methods signature, so you are encouraged or obbligated to manage these exceptions and their relative problems. These exceptions represent an error that should probably occur during particular code execution, like a parsing error, or an input output error. For this type of problems we have particular exceptions, to catch and easily manage them (for example as previously said to init a variable with a default value after an error).

The second type of those exception represents instead some generic problems that can occur during program execution. They are a big and generic set and generally their probability of occurring is low. For this reason you are not obbligated to manage them. The main example of this type is the general Exception class.

So an catching an Exception is not the right approach to solve a bug, as suggested by Gabe Sechan.

Catching a generic Exception in the main() Java method can be a way, for example, to show a default human readable error to the user if nothing else is available. Or could be a way to keep the failing of the current operation reducing crash probability.

Now, in Android we can't act directly on the main() method. onCreate() method is executed and exited so catching here a generic Exception has no much sense. Obviously it depends also on what you do in your onCreate() method and what you want to do if an error occurs. You could do some strange stuff (is very defined what you should do in the onCreate() method) and you could need to manage a big set of problems only showing an error, so it has more sense catch only a generic Exception than a lot of particular exceptions to make the same thing in each catch block.

If you want to achieve this goal (a message showed for all the errors occurred during onCreate() execution, made Activity by Activity) this is the right approach.

If instead what you want to achieve is to intercept all of the errors that are generated during all of your app execution, a good approach could be the UncaughtExceptionHandler, that act similarly to catch a generic Excepetion into a Java main() method. At this level an interesting approach is described here.

For more infos about exceptions you can read this and this.

Community
  • 1
  • 1
firegloves
  • 5,581
  • 2
  • 29
  • 50
  • 1
    THat's a horrible idea. Just putting up an exception handler is unlikely to work (the app is unlikely to be able to continue correctly) and is a bad practice. Figure out the error and fix it. – Gabe Sechan Jan 21 '17 at 16:36
  • 2
    what are you saying? depends on which error it is. Mine is only an example, app execution after the exception depends on how you handle the exception. As mentioned in OOP manuals... – firegloves Jan 21 '17 at 16:43
  • I'm saying that a generic exception handler doesn't work. You need to solve every exception independently. Basically every time you see an exception, you have a bug to fix. Exceptions don't just happen randomly. – Gabe Sechan Jan 21 '17 at 16:44
  • 1
    No, I disagree. An exception may occurs due to a connection problem for example. This is not a bug. In this case, for example, you could catch your exception and setting needed variable to a generic value that does not block app execution. – firegloves Jan 21 '17 at 16:46
  • Hint: YOu don't know what exception you just caught. Are you OOM? Continuing will either not work or give undefined results. Are you dereferencing a null pointer? At best you won't work, at worst you'll give incorrect results. WHat actually happened? YOu don't know. It may be acceptable to catch a specific exception, it is NOT acceptable to do a catch all. – Gabe Sechan Jan 21 '17 at 16:49
  • Oh ok, now I've understood, I was not talking about generic Exception. I repeat: mine was only an example. Keep calm man, we are only speaking about coding – firegloves Jan 21 '17 at 16:52
0

THat's the wrong way to go about it. Instead, go into your logcat. Read the stack trace of the exception. Figure out what you did wrong. Fix it. Just catching exceptions is a horrible practice unless you're catching a specific exception for a specific reason- its very unlikely your app is in a state where it can continue correctly. Don't be lazy, track down your bug and fix it.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127