Exception handling, should I catch each specific exception?

I just thought about it. I need to handle the KeyNotFoundException by catching this particular exception, or I can just use an "empty" catch like this:

try
{
    //Code goes here
}
catch
{
}

      

Or I need to do it like this:

try
{
    //Code goes here
}
catch(Exception ex)
{
}

      

Or I need to do it like this:

try
{
    //Code goes here
}
catch(KeyNotFoundException ex)
{
}

      

The reason I ask is because when I look at the crash count in the App Hub, I have a lot of crashes related to "KeyNotFoundException" but I never experience any crashes in my application. Could it be a problem that I don't catch the specific exception and that the App Hub crash statistics classifies it as a crash, even if the exception is being handled?

EDIT: Below are some screenshots of App Hub crash statistics (Stack Trace). Does anyone know what this means? This has to do with my background agent and this may be the reason why I have never experienced any crashes in my application:

enter image description here

enter image description here

enter image description here

+3


source to share


6 answers


No, the market only calculates unhandled exceptions, so your app crashes.

Empty Tricks or Traps Exceptions are the most common catches (every exception comes from the base Exception class, so you'll catch it all.), Critical code is somewhere where you don't use try-catch. Based on the exception, you should check your dictionaries and think about what conditions might cause the error.

It is generally good practice to validate the parameters in your public methods, so if any problem occurs, you can provide more helpful error messages such as:



public User GetUser(string username)
{
    if (String.IsNullOrEmpty(username))
        throw ArgumentNullException("username");
    return this.users[username];
}

      

In this case, if something goes wrong, you will see that you used null for the username, otherwise you will see a KeyNotFoundException. Hope this helps, good luck!

+3


source


You can use a base exception to catch a more derived exception, so it Exception

will catch KeyNotFoundException

because the latter inherits the former. So strictly speaking, if you want to catch "any" exception, it catch (Exception)

will suffice.

However, you should only catch exceptions if you can handle them in any meaningful way. Though I'm not sure how this mindset stacks up against WP development.



As for your main problem, I have no idea. Does the App Hub contain any crash details such as stack traces?

Your best bet is to leave the template code in place that is logged for the unhandled exception event, and put some records in your application to record as much information as possible about the state of the application at the time of the crash.

+2


source


No, you don't need to catch every specific type of exception in a try / catch block, see the C # language link .

However, instead of wrapping all of your code in try / catch blocks, you probably want to add exception handling logic and step into a handler for Application.UnhandledException . See this excellent blog post for an example of how to handle this event.

+1


source


If you are interested in a specific exception, for example KeyNotFoundException

in a certain part of the code, you catch it like this:

try
{
    //Code goes here
}
catch(KeyNotFoundException ex)
{

}

      

If you want to catch a specific exception and some are undefined, you would do something like this

try
{
    //Code goes here
}
catch(KeyNotFoundException ex)
{

}
catch(Exception ex)
{

}

      

If you want to prevent your application from crashing, use the Collin example with the Application.UnhandledException event.

+1


source


You can catch all exceptions by catching the base class, but whether you want from what you are trying to achieve.

Generally speaking, you only have to catch the exception at the level at which you have knowledge to decide what should be done about the error, i.e. discard some actions or display a message to the user. It often happens that at a certain level it makes sense to catch a specific type of exception, since that level of code understands what that means, but it might not make sense to catch everything.

Avoid catching everything too early, there are exceptions to tell you that something is wrong, the catch blanket ignores it and may mean that your program continues to run but starts behaving incorrectly, possibly corrupting data. Its often better to "fail sooner or later" when you receive unexpected exceptions.

+1


source


As others have said - No - you don't need to catch a specific exception, catch an Exception, or just catch the exception to bubble up.

However, you should simply catch certain exceptions where possible to make your code more explicit about what it does. Better to repeat the validation before a potential error condition - again this is covered in other posts.

For your specific problem, the link you provided indicates that it is a problem reading values ​​from isolated storage (IsolatedStorage.get_Item) - so when you access IsolStorage during a ScheduledTaskAgent call, you need to make sure the item exists before getting his. Perhaps some configuration settings are missing or something else?

+1


source







All Articles