I am learning C# & .netmf so this may seem like a silly question. But i have seen many examples in the last few days. I have notices that some use many Try Catch statements, some use little and others dont use any.
My question is how does one know when to use Try Catch and when not to.
I come from a C background so Try Catch is a new thing.
If you lookup a NETMF method you’ll see what exceptions it can throw. Try to catch them 
gotcha, thanks!
And if you dont, does the processor go off into the weeds ?
Use try { … } Catch { … } finally { … }
Finally can be used for release big memory object if catch exception or not
The big thing to remember about Try…Catch is don’t do it unless you can actually do something with the exception to help solve the problem or provide more info to the user about the problem. So much code I get from others looks something like this…
try
{
blah;
blah;
blah;
}
catch(Exception ex)
{
throw ex;
}
That adds absolutely nothing to the problem. A lot of people new to C# seem to think that every block must have a try…catch. Not true.
thank you, i am slowly catching on…
Not every block, but Main () and all public Method / Property(with code).
And all private code where you except a exception ( if sensor disconnected, …)
At least, put Debug.Print ( “…” + ex.Message ) ;
I might agree with main() if you did more than just Debug.Print(ex). If you don’t explicitly call Debug.Print() what will happen? The exception will be printed to the debug window… But having the catch here makes a convenient place to stop the debugger to view the exception. I wouldn’t agree to any general rule that says a public property/method has to have one. Again, it boils down to the question of “if I catch the exception, can I do something to allow the program to continue?” If not, then all you’re doing is writing unnecessary code.
I’m OK with that. I think catch on main is provide by my 8 years of C# desktop development
And on this case Debug.Print is replace by log system.
BTW, jdal, try…catch is one of the many things that originated in C/C++ (with improvements).
Another thing worth mentioning considering you’re new… Be sure you’re aware of the InnerException property of every exception. C# exceptions can be a hierarchy and (if thrown correctly) you can always walk that hierarchy down to where the exception originated. Thus, it is not necessary to catch the exception at every function and re-throw it unless you have something useful to add.
[quote]BTW, jdal, try…catch is one of the many things that originated in C/C++ (with improvements).
[/quote]
Never done c++. seems more like a glorified if else statement.
No, big difference. The structure is actually more like a [italic]switch [/italic]statement. Code will only drop into a [italic]catch[/italic] if an exception (error) is thrown in the try block. You can have any number of [italic]catch[/italic] statements if you have multiple types of exceptions you think you may encounter. The [italic]finally[/italic] always gets executed even if there is an exception. That’s important so you can always clean up.
oh ya, now that you bring that up i remember reading that you can have multiple catch statements for different errors. ok, then its sounds like a glorified switch statement 
I think you’ve got it… But, instead of a switch based on logic it’s a switch based on the unknown. One other trap people new to C# fall into that I’ll warn you of… Try…catch isn’t there to replace logic or anticipation of problems. It’s there to give you a way to handle those things that can’t be handled any other way. There is a performance hit you take when an exception is thrown and it’s also a pain when debugging because the debugger will always stop in a catch by default. What I mean is don’t do this…
double Divider(double x, double y)
{
try
{
return x/y;
}
catch (DivideByZeroException ex)
{
return 0;
}
}
When you could do this…
double Divider(double x, double y)
{
if( y == 0 ) return 0;
return x/y;
}
Huh, interesting thanks for the great tip.
Another thing you always should check.
If you are sing an API method check documentation on what exceptions it can throw. Sometimes documentation explains how you should handle particular exceptions.