Difference between throw new Exception with no surrounding catch and putting this in a catch?

What is the difference (if any) in writing:

if (File.Exists(filePath)) 
    //Something
else
    throw new FileNotFoundException();

And surrounding the if/el开发者_JAVA百科se block, above, in a try brace with a catch.

In fact, is the catch needed? If so, what would it catch? Or perhaps a better comparison is to put the if part of the above block in a try brace (without the if statement) and catch a FileNotFoundException, throwing up the call stack (throw).

Thanks

I don't see any reason to throw an exception that would be thrown anyways. It might be more useful to throw an exception with a higher level of abstraction though.

By surrounding the if block with a try catch means you are going to have to handle the missing file there and then in the catch (see @lukas's answer). If you are going to handle the missing file in this code, then you don't need the else-throw, because you already know the file is missing from the first if. On the other hand, if you want the calling code (somewhere higher up the call stack) to handle the missing file, then passing that information on in an exception is ok, but you don't want to then go an wrap the throw in a try-catch because it won't get thrown out of this block of code.

One is safer than the other.

When you check if a file exists, nothing guarantees that file is there further down the execution of the method.

If you surround it with a Try / Catch block, you can elegantly catch the glitch, act accordingly and wrap up any thing you want to in the Finally block. For example, closing the stream to the file.

Yes, catch is needed, because of race condition. Other process/thread can delete/change/move/etc. the file. And you cannot prevent it.

try
{
  using (//your file opens here)
  {

  }
}
catch (FileNotFoundException)
{
  // handle FileNotFoundException
}

Exception handling is an application concern. If you are interesting in either (a) an exception or (b) a specific exception then you use try/catches.

Since exception handling is many orders of magnitude slower than an if check, and you know the file may not be present, then you can either take the performance hit, or write your code as you have. It's simply your choice in taking the performance hit on the occasions the file isn't present.

There are people who say you should only catch an exception if you can do something about it, and in the main they are correct however there is a certain place I always use exception handling.

• When returning from across a service boundary. Sometimes this is security related (hiding implementation details) though mostly to improve runtime diagnostics
• When issuing a call across a service boundary. This is usually reliability related, though again most to aid trouble shooting.

When using exception handling for diagnostics I essentially just log the exception and raise back up.