Performance with Try Statement question

D

Denaes

Senior Contributor
Joined
Jun 10, 2003
Messages
956
When I was learning VB6 my teacher told me to be careful about when to use Try Statements because it ate up performance, especially Try's within Try's.

Well I'm working on a huge .Net database application and I see tons of places that I'm using Try Statements. Pretty much whenever I'm attempting to add a record or fill a datatable... I guess I'm playing it safe.

Our customers won't be using 4ghz PCs, but they're not going to be using 800mhz machines either. Probobly somewere in the middle.

Is there still a performance stigma around Try statements? In a lot of books I'm reading they use them all the time without any notes about performance or costing extra memory or anything.
 
Exceptions (in a release build anyway) incur virtually no overhead for the 'normal' (read error free) code path. There can be a performance hit when an exception is throw though; then again something has just gone wrong in your app, performance is probably not your uppermost concern...

Even if there is a noticable performance hit often there isn't any alternative way of detecting / handling failures under .Net anyway.

Personally I'm with Diesel on this on, Exceptions are great and your tutor probably wasn't that great.
 
The big thing you don't want to do (and sadly, I've seen this) is use try..catch as a means of control flow. For example, check for a null return from the DB before you try to use the returned value, especially if it's possible that the value could be null. Exceptions should only be used to catch exceptional things -- things that aren’t really supposed to happen. It sounds like you're doing the right things for the most part.
 
Realistically, even if you throw a moderate amount of exceptions the impact on performance will be minimal. It is generally described along the terms of "Exception handling will only have a significant impact when exceptions are actually thrown." But "significant" is a subjective and relative thing. The first exception may take a half a second or so (probably less, it tends to be significantly less in version 2.0 than in version 1.x), and after that you need to throw a lot of exceptions before you begin to notice any degradation in performance. Besides, as has been said, if you are using exceptions correctly then when an exception is thrown, performance should be the last concern. And there is no other way to do everything that exceptions do (IIRC, On Error uses exceptions behind the scenes).
 
Yeah, the way I see it, you should do what you can to prevent an exception. Check for Null/Nothing's, make sure you're not dividing by zero, etc.

But after the fact, if an error still slips by, bad performance or not, I'd rather have it Caught than to throw an Error.

What I was most worried about was that even successful code within a Try would add overhead, which doesn't seem to be the case.

Next step, mastering all of the Exception Types and how they relate to each other and interact with SQL Server Exceptions. :(

Did I mention that Exceptions aren't the most interesting things to play around with?
 
Back
Top