Using try/catch for preventing app from crashes

Pasting a paragraph from Android documentation -

I'll entitle it as -
Don't Catch Generic Exception

It can also be tempting to be lazy when catching exceptions and do something like this:

try {
    someComplicatedIOFunction();        // may throw IOException
    someComplicatedParsingFunction();   // may throw ParsingException
    someComplicatedSecurityFunction();  // may throw SecurityException
    // phew, made it all the way
} catch (Exception e) {                 // I'll just catch all exceptions
    handleError();                      // with one generic handler!
}

In almost all cases it is inappropriate to catch generic Exception or Throwable (preferably not Throwable because it includes Error exceptions). It is very dangerous because it means that Exceptions you never expected (including RuntimeExceptions like ClassCastException) get caught in application-level error handling.

It obscures the failure handling properties of your code, meaning if someone adds a new type of Exception in the code you're calling, the compiler won't help you realize you need to handle the error differently.

Alternatives to catching a generic Exception:

• This one is my choice - Catch each exception separately as separate catch blocks after a single try. This can be awkward, but it is still preferable to catching all Exceptions. Beware repeating too much code in the catch blocks.
• Refactor your code to have more fine-grained error handling, with multiple try blocks. Split up the I/O from the parsing, handle errors separately in each case.
• Rethrow the exception. Many times you don't need to catch the exception at this level anyway, just let the method throw it.

In most cases you shouldn't be handling different types of exception the same way.

It's definitely a bad programming practice.

From the current scenario, if there are hundreds of try catch like this, then you won't even know where the exception occurs without debugging the application, which is a nightmare if your application is in production environment.

But you can include a logger so that you get to know when an exception is throws (and why). It won't change your normal workflow.

...
try {
    View view = findViewById(R.id.toolbar);
}catch(Exception e){
    logger.log(Level.SEVERE, "an exception was thrown", e);
}
...

I have been developing android apps for the past 4-5 years and never used a try catch for view initialisation.

If its a toolbar do like this

Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);

eg:- To get a TextView from a view(fragment/dialog/any custom view)

TextView textview = (TextView) view.findViewById(R.id.viewId);

TextView textview = (TextView) view.findViewById(R.id.viewId);

instead of this

View view = findViewById(R.id.toolbar);

A view object has minimum reach compared to its real view type.

Note:- May be it crashed because the view was loaded. But adding try catch is a bad practice.

I would put this as a comment to some other answer, but I don't have the reputation for that yet.

You are correct in saying that it's bad practice, in fact what you posted shows different types of bad practice in regards to exceptions.

1. Lack of error handling
2. Generic Catch
3. No intentional exceptions
4. Blanket Try/catch

I'll try to explain all of those via this example.

try {
   User user = loadUserFromWeb();     
   if(user.getCountry().equals("us")) {  
       enableExtraFields(;)
   }
   fillFields(user);   
} catch (Exception e) { 
}

This can fail in several ways that should be handled differently.

1. The fields will not be filled, so the user is presented with an empty screen and then... what? Nothing - lack of error handling.
2. There's no distinction between different types of errors, e.g. Internet problems or problems with the server itself (outage, broken request, corrupted transmission, ...) - Generic catch.
3. You can not use exceptions for your own purposes because the current system interferes with that. - No intentional exceptions
4. Unessential and unexpected errors (e.g. null.equals(...)) can cause essential code not to execute. - Blanket try/catch

Solutions

(1) First of all, failing silently is not a good thing. If there's a failure, the app won't work. Instead there should be an attempt to resolve the problem or a display a warning, for example "Could not load user data, maybe you're not connected to the Internet?". If the app is not doing what it's supposed to, that's way more frustrating for a user than if it just closes itself.

(4) If the User is incomplete, e.g. the country is not known and returns null. The equals method will create a NullPointerException. If that NPE is just thrown and caught like above, the fillFields(user) method will not be called, even though it could still be executed without problems. You could prevent this by including null checks, changing execution order, or adjusting the try/catch scope. (Or you could do save coding like this: "us".equals(user.getCountry()), but I had to provide an example). Of course any other exception will also prevent fillFields() from being executed, but if there's no user, you probably don't want it executed anyway.

(1, 2, 3)Loading from web often throws a variety of exceptions, from IOException to HttpMessageNotReadable exception to even just returning. Could be that the user isn't connected to the internet, could be that there was a change to a backend server or it is down, but you don't know because you do catch(Exception) - instead you should catch specific exceptions. You can even catch several of them like this

try{
   User user = loadUserFromWeb(); //throws NoInternetException, ServerNotAvailableException or returns null if user does not exist
   if(user == null) { 
       throw new UserDoesNotExistException(); //there might be better options to solve this, but it highlights how exceptions can be used.
   }
   fillFields(user);
   if("us".equals(user.getCountry()) {
       enableExtraFields();
   }
} catch(NoInternetException e){
    displayWarning("Your internet conneciton is down :(");
} catch(ServerNotAvailableException e){
    displayWarning("Seems like our server is having trouble, try again later.");
} catch(UserDoesNotExistException e){
    startCreateUserActivity();
}

I hope that explains it.

At the very least as a quick fix, what you could do is send an event to your backend with the exception. For example through firebase or crashlytics. That way you can at least see stuff like (hey, the main activity does not load for 80% of our users due to a problem like (4).

This is bad practice. Other answers have said that but I'd think it's important to step back and understand why we have exceptions in the first place.

Every function has a post-condition – a set of things that must all be true after that function executes. For example, a function that reads from a file has the post condition that the data in the file will be read from disk and returned. An exception, then, is thrown when a function has not been able to satisfy one of its post-conditions.

By ignoring an exception from a function (or even effectively ignoring it by simply logging the exception), you're saying that you're ok with that function not actually doing all the work it agreed to do. This seems unlikely – if a function does not run correctly, there is no guarantee that what follows will run at all. And if the rest of your code runs fine whether or not a particular function runs to completion, then one wonders why you have that function in the first place.

[Now there are certain cases where empty catches are ok. For example, logging is something that you might justify wrapping in an empty catch. Your application will probably run fine even if some of the logging can't be written. But those are special cases that you have to work really hard to find in a normal app.]

So the point is, this is bad practice because it doesn't actually keep your app running (the supposed justification for this style). Maybe technically the OS hasn't killed it. But it's unlikely that the app is still running properly after simply ignoring an exception. And in the worst case, it could actually be doing harm (e.g. corrupting user files, etc.).

Yes, try/catch is used to prevent app from crashing but You certainly don't need try/catch for fetching a view from XML as depicted in your question.

try/catch is generally used while making any http request, while parsing any String to URL, creating URL connections, etc. and also make sure to print stack trace. Not printing it doesn't make much sense in surrounding it with try/catch.

It's bad practice to use catch(Exception e){} because you're essentially ignoring the error. What you probably want to do is something more like:

try {
    //run code that could crash here
} catch (Exception e) {
    System.out.println(e.getMessage());
}

We pretty use much your same logic. Use try-catch to prevent production apps from crashing.

Exceptions should be NEVER ignored. It is a bad coding practice. The guys maintaining the code will have a really hard time localizing the part of code that raised the exception if they are not logged.

We use Crashlytics to log the exceptions. The code will not crash (but some functionality will be disrupted). But you get the exception log in the dashboard of Fabric/Crashlytics. You can look at these logs and fix the exceptions.

try {
    codeThatCouldRaiseError();
} catch (Exception e) {
    e.printStackTrace();
    Crashlytics.logException(e);
}

While I agree with the other responses, there is one circumstance I have repeatedly encountered where this motif is marginally tolerable. Suppose someone wrote a bit of code for a class as follows:

private int foo=0;

    . . .

public int getFoo() throws SomeException { return foo; }

In this circumstance, the 'getFoo()' method cannot fail - there will always be a legitimate value of the private field 'foo' to be returned. Yet someone - probably for pedantic reasons - decided that this method should be declared as potentially throwing an Exception. If you then try to call this method in a context - e.g an event handler - which does not allow an exception to be thrown, you are basically forced to use this construct (even then, I agree that one should at least log the exception just in case). Whenever I have to do this, I always at least add a big fat comment 'THIS CANNOT OCCUR' next to the 'catch' clause.

A nice article on the topic:

Why your app should crash

Too many times I've seen developers trying to avoid crashes at all cost. Actually, sometimes you want your app to crash. Jeroen Mols explains why and gives some practical tips.

(from Android Weekly)

This is bad for multiple reasons:

1. What are you doing that findViewById throws an Exception? Fix that (and tell me, because I've never seen this) instead of catching.
2. Don't catch Exception when you could catch a specific type of exception.
3. There is this belief that good apps don't crash. That's not true. A good app crashes if it must.

If an app goes into a bad state, it is much better for it to crash than for it to chug along in its unusable state. When one sees an NPE, one shouldn't just stick in a null check and walk away. The better approach is to find out why something is null and either stop it from being null, or (if null ends up being a valid and expected state) check for null. But you have to understand why the issue occurs in the first place.