When to use try catch statements

Since this can be a highly debatable subject, I will tell you what I do personally.

I usually use try/catch blocks when I am dealing with certain technologies - for example input/output of data objects or streams of data. I also will use it a little more in initial pilot development and then remove them after regression testing. There are times when some things really just are unpredictable and you want your application to make sure the user is notified and your program crashes gracefully. Another thing to think about is that it is generally preferred to do checks for code that can CAUSE an exception (null values, empty objects, etc.) before executing code (thus eliminating the need for try/catch). Something like (pseudo code):

if (myObj == null) { // fail and let user know }
if (myObj.Name === "") { // fail and let user know }

However sometimes there are simply too many possible exceptions available that you check for the most common and catch the rest. So something like (pseudo code):

try
{
    //do something that might cause an exception
}
catch (NullValueException){}
catch (InvalidArgumentException){}
catch (CustomException){}
catch {}

The reason this topic is generally confusing for newer programmers is because you get a lot of opinions and talk about compute cost, nesting headaches, bubbling, etc. All of that is valid and important - but don't let it overwhelm you. Most tasks/routines you write in your software will not need a try/catch block. If you are worried the method you are coding is getting too complex to check for all possibilities, try wrapping some of the code that has the possibility to generate an exception in known exception types and start that way. Don't worry about compute costs in initial development as you can shave off cpu cycles later on.

I will say you should stay away from the general catch - one catch for all exceptions. This is generally bad practice and not recommended...well...ever. One reason being it provides NO HELP to you or anyone who may be possibly using your framework, library, objects, etc. I can't say you will always be able to find a way to get around the general catch, but I'd try really hard before doing it.

// BAD CODE
try
{
    // do something that might cause an exception
}
catch {}

Not sure if that really helped you out, but I get your concern. I'd say don't invest too heavily in the "right" way to do it - start feeling out your code and adapt. If you are getting unhandled exceptions during development phases, throw a try/catch in there and start catching those exceptions until you've hammered out what is causing the problems. Good luck!

These points may help clear things up:

• you may be confusing the term "exception" with "exemption".
• an exception is only expected if it is generated by your own program
• exceptions can also be generated by the system, and those might be prepared for even if not expected

A reason you might use an exception instead of a direct test could be that the place you wish to test for some condition might be in a different scope, such as inside a function you are calling. The function can cause an exception which the caller can catch, even if the caller did not have access to the values needed to determine the condition itself.