I see people are using try without handling the catch. Is there a point to this or is it just good coding practice?
byte[] data = Encoding.UTF8.GetBytes(getTicks() + "\"\r\n");
try
{
fileStream.Write(data, 0, data.Length);
}
catch { }
It’s fine.
Basically, you have no idea if the next operation is going to succeed or not, and you don’t really care, so you just catch nothing.
Within the catch statement, you can check the cause of the error. If you don’t care about this, then an empty catch is enough 
I wouldn’t say it’s good or bad practice, but indeed, it’s quite common.
well its lazy but effective
To be correct. You are actually catching everything you just don’t do anything about it.
Old-time (pre-.NET) VB developers know this as “On error resume next”… could be handy at times but can also lead to some nasty bugs. In the embedded world you might take more risks (less parameter checking, etc.) to get the performance you need, with the right amount of testing.
Which is faster?
try{
//something
}
catch(){}
- OR -
try{
//something
}
finally{}
My point is why try to catch something if it’s not handled.
Wouldn’t the compiler just translate it into;
byte[] data = Encoding.UTF8.GetBytes(getTicks() + "\"\r\n");
fileStream.Write(data, 0, data.Length);
oh contraire - if the user removed the sd card (for example) then you dont want any nasty exceptions, and maybe handle it later, having said that I think exception handling is the best software invention since the stack, I can remember the days of api’s haviing return values ad inifinitum blah blah blah
@ upside down chris - I thought I read (will have to do some research) that finally is becoming looked down upon … From the top of my head (which is cluttered with too much junk) I think the concern was what if the finally code caused an exception.
I digress … this looks like my code from my class on Fezzer.
If so, it’s for a SD data logger for my non-tethered autonomous vehicle.
So if there was an error writing data to the card - card is full, base stream closed, etc - there’s not much I cared to do. I could do a Debug.Print() but since there’s no one to see it, didn’t think it was necessary. In this case, the catch is there just to prevent an unhandled exception from having to be bubbled up the stack.
Additionally, because of the limited nature of the microcontroller, I didn’t consider the overhead of trying to open the stream or remount the SD card necessary. If it was for a desktop type app, then I would have done so.
The code, while being written, had a catch, but purely to have something to put a breakpoint on to see if the code failed.
FWIW - in my daytime development, I pretty much always have a catch.
If this is my code, that was the point. Otherwise the exception would have been bubbled up to the previous frame on the stack to see if there was an exception handler. If that didn’t it would have went up to the next frame, etc etc, eventually to be handled by the (I think) CLR.
In this case I didn’t care about the exception at all (see above post for context).
Those HResult long ints were the death of me!
With that mentality, what if the code outside the catch throws an exception? What then, HUH?
You put that in a try/catch as well 
But as with most things in programming, everyone has their reasons for doing it their way. Doesn’t mean one set of opinions are better than others, assuming they work and doesn’t create spaghetti logic.
I rarely use finallys - only if makes sense to me at that point.
Doesn’t mean my way is right. It just means my years of experience led me to this destination. Others experiences led them to different destinations … like not using underscores in variable names :dance:
I’ll do some performance evaluation on it tonight. I have a feeling catch() will be faster, but we’ll see.
the idiom is…
try
{
}
catch
{
}
finally
{
}
Personally Ive never (much) used the finally clause it just never seemed to help
The control structure “finally” defines the block that will be executed regardless of the outcome of the try block.
The only reason I say it would be used in this situation is because it is a second way of terminating the “try” control structure.
It doesn’t really matting is you use “finally” or “catch()”, they will both do the same thing in the context of not giving a damn about the outcome of the “try”.
mmm sorry need to get brain into gear
Try, Finally and Catch serve different purposes
Try says - please try and execute this code
Catch says - if there was a problem then run this code
Finally says - no matter what, run this code before the function returns
“finally” is good to release any unmanaged resources and do “final” cleanup. Third party tools use it a lot too. For example EQATEC Profiler injects “try…finally” block around a method’s body and measures execution time in the “finally” part.
You almost never want to hide/swallow an exception like that unless its expected to happen and you do something with it. For example, open a file would be ~normal to get file not exist or can not open for read. So you could catch it and report back to user or something else. But that is not really exceptional, but logic flow. Unexpected exceptions, normally would mean bug, retry situation, or stop with logging and cleanup.