Making use of exceptions in code...C# File IO exceptions

I have a question reagrding proper programming practice when dealing with exceptions. We have production code like:

try 
{

File.Copy(s开发者_如何学JAVArc,dest);

}
catch(Exception ex)
{
  ShowMessageToUser(ex.Message); 
}

Is this a good practice? I thought that we should always make use of specialized exceptions and catch them....on the other hand, I do realize that File.Copy can throw several different exceptions and it will be a pain to write a catch block for every exception...? So what should be done in this case....Is there a set of file specific excepion collections that we can use to catch?

Thanks , any comments are welcome.

As a general practice, I would say this is not a good practice. Personally, I would handle this with separate exceptions, and only handle the exceptions you can be handle correctly.

In this specific scenario, I would also avoid this. I would prefer to handle the explicit exception types, if for no other reason than to customize the message to the user.

This is mainly because exception messages are really not intended for an end user - they're messages meant to be interpreted by a developer. I feel that directly showing an exception message to a user, especially for an operation where an exception is likely, is a bad practice.

You should handle each exception, and provide a meaningful message to the user that makes sense in the context of this operation.

File.Copy can only throw 8 types of exceptions - handling every one, with a message, is only 32 lines of code - that's really not that much when you consider the extra benefit of having a clear, meaningful message in all cases presented to the end user.

IO is generally a pain for this reason- there are so many things that can go wrong. It would be best for you to:

• Do everything you can to avoid exceptions by checking all parameters before calling File.Copy. Remember that in .Net exceptions can have severe performance costs due to the generation of a stack trace.
• Catch the exceptions that you know you are capable of handling. For some exceptions you might want to display an error message and ask the user for new input.
• If you can't handle an exception right there, do not catch it! Exception swallowing is the source of all evil. Reporting an error message is only slightly better than exception swallowing and will only confuse the end user.

It may seem like a lot of work, but sometimes a lot of work is necessary to produce a stable program.

You use specialized exceptions in order to perform different actions based on the type of error you got. If all you want is to show the user the default error message... then your code is sufficient.

But let's say for example that you would like to log the exception if it happened because of security issues... you would write something like:

catch (PermissionDeniedException ex)
{
    Log(ex.foo);
    ShowMessageToUser(ex.Message); 
}
catch(Exception ex)
{
    ShowMessageToUser(ex.Message); 
}

And remember to always go from more specific to more general exceptions.

Yes that's a bad Practice and you should use specific Exceptions and then general Exception lower the catch block.

If you feel that they are too many then you should at least create catch blocks for most Anticipated file Specific Exception and then have usual Exception catch block

Your example is very easy to implement, but hardly best practices. As a general rule

• Only catch Exceptions you are actually interested in handling at this point. Let everything else bubble on to be handled elsewhere.
• You can also use superclasses to catch a specific group of exceptions.
• Do not use exceptions for things that are not errors. For example, if the user supplies the file name for the copy, you can check beforehand if the file exists, instead of relying on an exception. Exceptions are for "exceptional circumstances", not for foreseeable conditions.
• If you're hacking a quick script, however, feel free to use the exception as in your example ;-)