Try..Catch blocks always expensive? [duplicate]

Answer 1

While it is true that you should never use try..catch for program flow control, I am not aware of any performance issues IF no exceptions are actually thrown in the code

Answer 2

In general, in today's implementations, entering a try block is not expensive at all (this was not always true). However, throwing and handling an exception is usually a relatively expensive operation. So, exceptions should normally be used for exceptional events, not normal flow control.

Performance is only one factor to consider, though, especially in the modern world. If (for instance) you're doing something once in response to a user action, it probably doesn't matter from a performance standpoint whether you use an exception even when you could have done a proactive check instead, provided the exception happens quickly enough the user isn't jolted.¹ But if you're doing something in a tight loop that's going to run hundreds of thousands of times, or you're writing a web application that may need to handle a huge load, you'd probably want to avoid using an exception for a normal case.

---

¹ More than a decade ago I was responsible for enhancements to a .Net 1.1 "no touch deployment" application in which the first exception thrown took fully three seconds. This was a sufficient problem in one use case involving opening a file the user had asked for which might reasonably not be there that I had to add a check for file existence prior to trying to open the file, which is normally poor programming practice (just try to open the file and handle the exception if that fails), purely because the user experience waiting for that exception to get built was so poor. But that's probably not the world we live in now.

Answer 3

This is language-dependent, but as far as I know in Java, if no exception is thrown, there is next to no performance cost to having a try/catch.

So in your example of using pre-validated email addresses, what you have is fine.

Answer 4

Just to play devils advocate - I have found a great use for using Exceptions for flow control: The 'cancel' button.

If you have a function running on some service that may take 10-120 minutes, which is doing a bunch of different things, I've found that doing if(hasCanceled) throw new JobCancelledException() inside of my Log() function (which logs at each step that I'm at) to work just friggan awesome. It bails out of the current execution of code and stops running the job - exactly what I need. I'm sure there's some better way to do it, maybe somehow using events - but for my case it works great (especially since jobs are not regularly cancelled).

Other then that though - I'm 100% in agreement that Exceptions should never be used as a flow control tool..

@Kornel - I have two words for that post... Holy $hit =)

here's a simple pseudo code sample:

Class Job
{
       Public Run(param1,param2,etc...)
       {
             Try
            {
                   Log("Doing Something")
                   DoSomething()

                         Log("Doing Another")
                         DoAnother()

                         Log("This keeps going, etc, inside of these function we make the same Log calls where it makes sense")
                         Etc()
                   }
                   Catch(JobCancelledException)
                   {
                        status="Cancelled"
                   }
            }

              Private Log(ByVal str As String)
              {
                      MessateToUser(str)

                      if(hasCancelled)
                          throw new JobCancelledException
            }

             private SomeEvent_WhenUserPushesCancelButton()
             {
                       hasCancelled=True
             }
}

Answer 5

They are pretty cheap unless there is an exception. So you should avoid them when an exception is expected, as in your example above.

I think exceptions on bad user input are generally unwise. Exceptions on out of memory or other unexpected failures are fine.

Answer 6

The overhead of the try block is very low, so if no exception is thrown then there should be no noticeable penalty. The main overhead that occurs when an exception is thrown is the stack walk that takes place looking for a handler - since you are caching the exception so close to the source, I doubt there will be much of a performance issue. Ideally though you would be able to validate your inputs properly beforehand, but email validation is fairly complicated so it may well not be worth it in this case.