Will Try Catch effect Performance if used to monitor code where no runtime exception can occurs

Question

I am using Try Catch for all my Database related operation. During this activity I use Try Catch even for statements where I am sending parameters to ADO.Net Procedure and not actually calling that Procedure. Will it effect performance of application if I am using Try Catch to monitor codes where actually Exception can never occurs.

Ex. 1)

Try { SqlParameter[] spParameters = { new SqlParameter("@Batch_ID", SqlDbType.BigInt), new SqlParameter("@Terminal_ID", SqlDbType.VarChar,8), new SqlParameter("@MID",SqlDbType.VarChar,15) spParameters[0].Value = nBatch_ID; spParameters[1].Value = strTerminal_ID; spParameters[2].Value = strMID; objResponse.ResponseValue = MyBlock.ExecuteDataset(strConString, "Insert_Act_Txn", spParameters); } catch(Exception Ex) { //logger function to write exception in log file }

Ex. 2)

SqlParameter[] spParameters = { new SqlParameter("@Batch_ID", SqlDbType.BigInt), new SqlParameter("@Terminal_ID", SqlDbType.VarChar,8), new SqlParameter("@MID",SqlDbType.VarChar,15) spParameters[0].Value = nBatch_ID; spParameters[1].Value = strTerminal_ID; spParameters[2].Value = strMID; Try { objResponse.ResponseValue = MyBlock.ExecuteDataset (strConString, "Insert_Act_Txn", spParameters); } catch(Exception Ex) { //logger function to write exception in log file }

In example-I am using try catch statement where I am creating parameter for procedure and assigning value to it where run-time exception can never occur and than calling actual procedure but in Ex.-2 I am using it only when I am actually calling this procedure.

Which way is good if I think from performance point of view

@@David: I din't get you. I am catching Exceptions to handle exception so that application work smoothly and exceptions get logged in some log file(I haven't writeen log code inside catch statement as it is only for Example) — user1888859
– user1888859, Commented Jan 22, 2013 at 7:51
Normally you catch an exceptions at the point where you need to handle the exception. I'd be surprised if you needed to handle it here. Your default approach when coding should be to not handle exceptions, and let a higher level method handle them. — David Heffernan
– David Heffernan, Commented Jan 22, 2013 at 8:05
Does that code compile? It looks like you are missing some closing } when you initialize your arrays. — HaemEternal
– HaemEternal, Commented Jan 22, 2013 at 8:25

daryal · Accepted Answer · 2013-01-22 07:53:46Z

Try has no performance overhead; you can use it safely; if you throw an exception it will have an performance overhead.

On the otherhand, Optimizations are not performed inside try blocks; but this not create an overhead unless you have proper code (you may refer to try-catch performance).

from msdn performance tips: "Finding and designing away exception-heavy code can result in a decent perf win. Bear in mind that this has nothing to do with try/catch blocks: you only incur the cost when the actual exception is thrown. You can use as many try/catch blocks as you want. Using exceptions gratuitously is where you lose performance. For example, you should stay away from things like using exceptions for control flow."

@daryal What do you mean? Where do you think this information should appear? It looks like implementation detail that has no place in the language documentation. And the information is right there in that MSDN perf. tip article. So what critical points are not mentioned?
@DavidHeffernan msdn does not mention about optimization of try blocks.
so you think no need to document critical points of a framework?
What makes you think that? Please describe precisely where these implementation details, that are subject to change, and that may vary from platform to platform, should be documented.
.Net framework does not seems to apply optimization of code inside try blocks. I have searched the msdn, but can not find any information regarding this.

Rockstart · Accepted Answer · 2013-01-22 09:00:28Z

Exceptions are always costly because…. Consider some of the things that happen when you throw an exception:

• Grab a stack trace by interpreting metadata emitted by the compiler to guide our stack unwind.

• Run through a chain of handlers up the stack, calling each handler twice.

• Compensate for mismatches between SEH, C++ and managed exceptions.

• Allocate a managed Exception instance and run its constructor. Most likely, this involves looking up resources for the various error messages.

• Probably take a trip through the OS kernel. Often take a hardware exception.

• Notify any attached debuggers, profilers, vectored exception handlers and other interested parties.

Do not use Try,Catch unless or otherwise needed.

But when you are using Database API's, we no longer have control of what can happen. And hence it is safe to wrap those calls with try and catch it with an appropriate SQLException.

Collectives™ on Stack Overflow

Will Try Catch effect Performance if used to monitor code where no runtime exception can occurs

2 Answers 2

5 Comments

Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

5 Comments

Comments

Related