Try ....​Catch....​Finally!?

Hi guys,
when is it NOT a good idea to use the Try--Catch --- Finally, in your code? and why not?

When you use try--catch --finally, what are the costs in terms of resources to your process? what actually happens?

is it a modification of the On Error Resume Next, or On Error Goto ErrorHandler, or ??????

Someone i know really loves the Try_Catch_Finally, and their code if filled with it. You can find it every where

hello there,

i am not sure what a catch does resource-wise, though i do notice it is somehow definitely slower than not having a try..catch at all (i.e. handling errors another way).

well, here are my two pennies:

what i've learned is that: a) only use try cathc if you know what you're doing with the e (exception). if it's just to display a messagebox, well, don't.

what i was taught in school also is that try..catch is not a must.
say, you can check for errors (most of them i think) without implementing a try..catch, e.g. file i/o. you can check the CanRead property to see if you are actually able to read from ia file, etc.
or if you try to open a file that is not there, do a if File.Exists(..) instead of try {open } .. catch.

what i do like is nested try..catch (but no more than 2 levels deep), because it is useful in some cases, and makes your code more readable.

if anyone knows what a try..catch means for your resources, please let me know i'm interested in knowing what exactly is happening there.

j

hardball wrote:

what i was taught in school also is that try..catch is not a must.

say, you can check for errors (most of them i think) without implementing a try..catch, e.g. file i/o. you can check the CanRead property to see if you are actually able to read from ia file, etc.
or if you try to open a file that is not there, do a if File.Exists(..) instead of try {open } .. catch.

It's not a must, it's a necessity.

Exceptions aren't meant to be used for program flow, that's why you should always have some kind of 'avoidance' conditional before calling a potentialy fatal function.

W3bbo wrote:

It's not a must, it's a necessity.

What I meant is that plenty of scenarios exist where potential traps and errors can (or even should) be handled differently, more cleanly, and more effectively.

Of course there are cases where you have to have a try catch. I agree with you, as will everybody else.

even if you check for file existense with Canread property, it is still adviseable to put the actual read code in Try/Catch, in case there's an error during the actual read process, no?

Threads should be wrapped in a try catch block if only so you can successfully catch ThreadAbortExceptions and do nothing with them.

Think about it this way.  If an exception is going to be thrown and you don't catch it, then your app will fail by throwing an exception and the end user will see garbage.

All code should be surrounded by at least 1 try catch block so you can trace what failed and hopefully fix it.  You don't need to include one in every single function, but at least make an effort to gracefully fail if your app has problems.

blowdart wrote:

Anatoly wrote: even if you check for file existense with Canread property, it is still adviseable to put the actual read code in Try/Catch, in case there's an error during the actual read process, no?

Yes.

Simple rule; exceptions are there for exception circumstances. So, for example, a file not being there is not exceptional, and could be checked for before you try to read from it. The hard drive exploding mid way through the read, and an IO error occuring is exception, there is no way to check for it before hand, so that will raise an exception, which should be caught at the point where you can react to the exception and handle it.

Sorry, but checking for a files existence in no way gaurantees the file will exist when the next statement is executed.  We're using multi-tasking OSes here.  The "exceptions are for exceptional conditions" only crowd often overlooks this concept.  Who defines what an "exceptional" condition is?

There's lots of good documentation available on this subject and you should do a web search on it.  If it help, including "Dave Abrahams" in the search is likely to be very helpful.  Even still, though, this is a very complex subject with many corner areas that aren't fully decided upon even by the experts.  Don't take the blanket statements made in threads such as this as gospel... this is one of those subjects you're just going to have to do more research on to fully understand it.

ScanIAm wrote:

Threads should be wrapped in a try catch block if only so you can successfully catch ThreadAbortExceptions and do nothing with them.

Think about it this way.  If an exception is going to be thrown and you don't catch it, then your app will fail by throwing an exception and the end user will see garbage.

All code should be surrounded by at least 1 try catch block so you can trace what failed and hopefully fix it.  You don't need to include one in every single function, but at least make an effort to gracefully fail if your app has problems.

Another case of what sounds like sound advice that's no universelly applicable.  You mention threads.  Having a try/catch around the main application function won't allow you to "fail gracefully" when your application has multiple threads.  Nor will simply placing threads in a try/catch always do so.  If you think exceptions are complex to begin with, once you've added threads into the mix you've got yourself the makings of a night mare.  The best thing you should do is try and ensure that most of your functions provide the "strong exception gaurantee", and document those that don't.

I don't see how try catch's could hurt. Like someone said they shouldn't be used for program flow, which I see some people using (a la catching error from dividing an unknown type by something and doing somehting else in the catch block). But for things like file operations or network operations, I see it as a rule to include atleast a high level Exception catch block if I don't know the specific errors possible yet. It takes care of a lot of headaches and keeps your application seem a lot more stable.

Cheers,
Aditya

Good article here.

I think my favorite one is to use try-finally even if you don't use try-catch, because if a callee throws an exception and your caller catches it, with a finally block, you can clean up whatever resources you need to. It's especially useful for closing IO streams.

Another is not to catch anything other than what you expect to catch. Otherwise your app will keep processing and eventually explode, and you'll have a nightmare trying to figure out what went wrong.

Quite often it is nice to see the MSIL code associated with it:

http://thehackman.blogspot.com/2006/01/try-catch-finally-disassembled.html gives a demo with a c# try..catch..finally block translated into MSIL.