error handling -> causes any performance issues?

[MrPolite]

I'm wrapping most parts of my code in a lot of try catch statements (wherever I can heh)
I'm wondering if using too many try catch blocks causes any performance issues

[RobDog888]

I believe it does but am unsure as to the extent. It was mentioned in a thread I was in before. Its when you nest multiple Trys that it will place a small drain on your resources. Try a search for it. I think it was less then 2 months ago.

[mendhak]

It does, yes, but it also depends on what you do. You should make sure your Catches are as specific as possible, and progressively move towards more generic catches. (Catch SystemDBComplexException ex.... and later, Catch Exception ex).

So you minimize the hit.

[MrPolite]

aaah no nested ones but they're almost all Systme.Exception ones
I dunno what errors can be raised... need more thought and consideration

[RobDog888]

Also try only to use them when there is a decent possibility of a failure and sparingly too.

Ps, Congrats on 4,004 posts

[MrPolite]

heheh thanks 4005 now I guess
umm to be honest I'm "scared" of unexpected error so I'm putting error handlers EVERYWHERE

there's a lot of unexpected stuff.... sigh
since you guys are saying there might be performance hits, I might reduce some of the error handling then

[RobDog888]

You may be over thinking the issue. Its common and hard to retreat from. Data input, database connections and data transactions are probably the two most potential areas for exceptions.


Ps, Congrats on 4005 posts

[jmcilhinney]

Further to what Rob said, there are a huge number of properties and methods that can throw exceptions but you are hardly going to wrap each in a Try block. For instance, indexing an ArrayList can throw an ArgumentOutOfRangeException, but who's going to allow for that under most circumstances? You would only employ exception handling on code sections that attempt things that are all or partly out of your control, like IO, data access and things like that. If you can't reasonably think of a scenario where your code could throw an exception then you generally shouldn't need to use exception handling. Then again, polite and reasonable are not the same thing. You should always consult the help topic for the current property or method to see what exceptions it can throw.

[MrPolite]

hehehehe
thanks for teh advice all
I'll see what kind of spaghetti code I can make

[mendhak]

You could just use lots of "On Error Resume Next" statements.


PS: That was humor. Don't take it seriously. Seriously.

[wossname]

Noteme gets really wound up when you mention Try{} blocks

[MrPolite]

ok I feel stupid
I'm calling Directory.CreateDirectory() and I could expect an IOException or an UnauthorizedAccessException to be thrown. So should I really create a catch block for both, and then a general one, in case another exception is thrown?

try
{
       Directory.CreateDirectory()...
			}
			catch (IOException)
			{}
			catch (UnauthorizedAccessException)
			{}
			catch (Exception)
			{}

I know this sounds retarded, but I'm a confused person

I would just go with catching a general System.Exception and nothing else
what should I do

edit: the reason I put multiple ones is because I thought it could be more efficient ? someone shoot me

[Edneeis]

I think the idea of catching exceptions is for handling them. You should catch specific ones that you plan to handle in that specific way otherwise group the exception types with their associated handling. So if you are going to handle an UnauthorizedAccessException the same as an IOException then why catch them seperate? Also keep in mind that if no local error handler is found it bubbles up the call stack to find one. So some general errors should be caught in a common handler that way only specific things need to be caught else where in the application.

[MrPolite]

I think the idea of catching exceptions is for handling them. You should catch specific ones that you plan to handle in that specific way otherwise group the exception types with their associated handling. So if you are going to handle an UnauthorizedAccessException the same as an IOException then why catch them seperate? Also keep in mind that if no local error handler is found it bubbles up the call stack to find one. So some general errors should be caught in a common handler that way only specific things need to be caught else where in the application.

okay
I was under the wrong impression that if I catch specific ones rather than a general catch statement, it would make it more efficient. I don't really plan to do anything with the exception.

[uk_codemonkey]

Actually, I'm also using Try...Catch extensively throughout my database application. Like Mr Polite, I'm so paranoid about my users doing things to break my application, every single subroutine that I write contains a Try...Catch clause. However, the only purpose for that being there is to remove the un-userfriendly error message, and throw it instead into the EventLog, replacing it on the screen with a friendlier-looking message.

However, my application seems to be running quite slowly, even on my development laptop which is pretty powerful. All of my applications run from a module called "Mod_Main", and everything is called from that. If I put a single Try...Catch statement into that Mod_Main, will that then negate the need to have every single exception handled?

[jmcilhinney]

Actually, I'm also using Try...Catch extensively throughout my database application. Like Mr Polite, I'm so paranoid about my users doing things to break my application, every single subroutine that I write contains a Try...Catch clause. However, the only purpose for that being there is to remove the un-userfriendly error message, and throw it instead into the EventLog, replacing it on the screen with a friendlier-looking message.

However, my application seems to be running quite slowly, even on my development laptop which is pretty powerful. All of my applications run from a module called "Mod_Main", and everything is called from that. If I put a single Try...Catch statement into that Mod_Main, will that then negate the need to have every single exception handled?

If you've written your code such that every method can throw an exception then you seriously need to rethink your design. Like I said previously, there are many properties and methods that can throw an exception, but you should have control over most of the circumstances that could cause those exceptions to be thrown. For instance, indexing a collection can throw an ArgumentOutOfRangeException, but if there is any possibility that the index is out of range then you should be using an If statement to test it first. Therefore there is no need for exception handling in this case. Be sensible and realistic with your exception handling. Perhaps you want to include a global exception handler so that your app will never generate an unhandled exception, but you should plan to never have to use it.

[uk_codemonkey]

Thanks to jmcilhinney for that reply. What I may well do is comment out a lot of the Try...Catch blocks for just now, and see if that causes the Exception to be handled in the Mod_Main subroutine. Hopefully the code'll run faster too

[szlamany]

If your TRY/CATCH is a sub-routine size TRY/CATCH, similar to the ON ERROR GOTO that was used in the past, then I do not believe it changes the size or execution speed of anything.

Every subroutine gets an error handler - regardless of whether you create it or if the compiler puts a default error handler into the object code.

Having lots of TRY/CATCH's nested is a lot different then a TRY/CATCH for the overall subroutine.

[uk_codemonkey]

Well actually, just as a test, I've just gone through the back-end code for one of the "busier" forms in my application, and commented out all of the Try...Catch...End Try statements, to see what would happen.

As far as I can tell, removing those hasn't made one iota of difference to the speed with which the form reacts to things like drop-down list selections and button-clicks.

[szlamany]

Well actually, just as a test, I've just gone through the back-end code for one of the "busier" forms in my application, and commented out all of the Try...Catch...End Try statements, to see what would happen.

As far as I can tell, removing those hasn't made one iota of difference to the speed with which the form reacts to things like drop-down list selections and button-clicks.

It would not affect the sppeed of drop down lists...

Each TRY/CATCH adds a small amount of code to be executed - making the "code space" in memory larger - adding a couple of instructions - but only where they are "encountered" at run time.

For a GUI type of form - speed would not be affected by TRY/CATCH use.