CODEWITHSUNDEEP
c#exception
Xaisoft
Xaisoft

Reputation: 46591

What is a better way to handle exceptions than the following?

At first, I was going to do something like the following:

public void WriteToFile(string filePath, string contents)
{
    try
    {
        File.WriteAllText(filePath, contents)
    }
    catch(Exception ex)
    {
        //Log error
    }
}

But then I decided to catch all the specific exceptions for the method WriteAllText, like the following:

public void WriteToFile(string filePath, string contents)
{
    try
    {
        File.WriteAllText(filePath, contents);
    }
    catch (IOException ex)
    {
        //An I/O error occured when opening the file
    }
    catch (ArgumentException ex)
    {
       //The exception that is thrown when one of the arguments provided to a method   
         that is not valid.
    }
    catch (UnauthorizedAccessException ex)
    {
       //Unauthorized access
    }
    catch (SecurityException ex)
    {
        //Security exception
    }
    catch (NotSupportedException ex)
    {
        //Invoked method not supported
    } 
}

The above is very verbose and with other methods, it could be more. Is there a better way to do this so I don't have to write so many catch statements. Also, if an exception is caught, is it best to return from it, log it. I always get confused on how to handle it.

I have noticed some confusion. I am going to handle the exceptions, I left out handling the exception to keep this short. I am going to make use of the ex variable. The question is more about doing just catch(Exception ex) or multiple catch statements.

I also bring this up because I always here that it is better to handle specific exceptions rather than a catch-all. If I have misunderstood this, please clarify on what it means.

Upvotes: 2

Views: 2553

Answers (4)

Jeffrey L Whitledge
Jeffrey L Whitledge

Reputation: 59443

Typicaly, your try/catch statements will be much further up the call stack from what you are showing in the question. There are two major reasons for this. First is that a low-level method will not know how to deal with an exception that happens within it, because it does not have enough context. If a low-level method (such as one that saves a document) does know enough about its circumstances to handle the exceptions, then that is a sign of a leaky abstraction. Second is that the program flow at higher levels will depend on whether the save operation succeeded or not. For these reasons, all of these types of exceptions are best delt with at the highest levels, such as in the UI layer.

That said, sometimes a long list of exceptions—as you have it—is exactly the way to go. If you need to handle a bunch of different circumstances, then it calls for a bunch of different catch statements, and that's just the way it goes.

Some of those exceptions, however, do not need to be caught. For example, an ArgumentException never needs to be caught. Instead, it is best just to pass the correct arguments every time. The only time an ArgumentException will ever need to be caught is if you are calling into a poory designed library in which you cannot know beforehand whether an argument is good or not. A well-designed library will provide alternatives to this.

So the list of catch statements could be made shorter, just by judiciously examining the circumstances of each type of exception and determining which ones are actually expected to happen.

Upvotes: 1

ColinE
ColinE

Reputation: 70122

The best method very much depends on the nature of your application and the expectations of the user. If you are creating a Word processing application and your operation above was to save the user's document, swallowing the exception and logging without notifying the user would be very bad! In this context, I would catch the specific exceptions so that I could better report to the user what the problem is.

If instead the file you are saving is non-critical, e.g. a period caching of some data that is retained in memory, you might want to simply log and not notify the user. In this context, I would go for a generic catch-all and just log the exception details.

Upvotes: 0

David V
David V

Reputation: 11699

It depends on how you are handling the exception. For example, if a SecurityException will cause you to present a dialog to the user to provide their credentials, then you should have a separate catch clause. If not, there is no need to explicitly call them all out.

E.g.

try
{
    File.WriteAllText(filePath, contents);
}
catch (SecurityException ex)
{
    //present dialog
}
catch (Exception ex)
{
    //All other exceptions handled the same
}

Upvotes: 2

Cole W
Cole W

Reputation: 15293

I agree with SLaks above. If you don't handle it there is no reason in catching specific exceptions. If you can handle certain exceptions but not others you should have a catch all that at least logs vital information about the exception.

Upvotes: 0

Related Questions