Way to automatically see which functions can potentially return exception in c#

Question

Hi,

nothing more frustrating than to see your code crash in the debugger on a method which exceptionned and you didn't try/catch it.

Is there an easy way to scan through your sources and tag all functions which can potentially throw exceptions?

Does the build in visual assist have some hidden option to colour these functions in a specific color?

thanks

R

Answer 1

All code but the most trivial could throw exceptions (out of memory, at the very least). You're probably better off writing your code defensively, with at least a global try/catch rather than trying to micromanage which sections of code will or won't throw exceptions.

Answer 2

I think the resharper gives you hints on exceptions. But due to the reason that C# doesn't support checked exceptions, there is way to determine the exceptions. Maybe code analysis tools like NDepend support this.

Answer 3

Everything can throw an exception. Check MSDN for a list of exceptions that can be thrown by a method.

Answer 4

No, there is no way to automatically do this nor is there a good way to get a list of all possible exceptions thrown by a method. Here are a few reasons why

1. Consider implicitly thrown exceptions such as StackOverflowException can be thrown at any time from any method. You must assume that any method in the CLR can throw these types of exceptions
2. Reflection and / or delegates can hide the actual code being called in a particular method so you cannot inspect all possible code paths of a method.
3. This would require inspecting IL vs. metadata.
4. In .Net there is no requirement to document exceptions that are explicitly thrown by an API

Answer 5

All non-empty methods can throw exceptions in one form or another. If you're concerned about exceptions you have personally generated, you can display them from intellisense in the same way framework methods do via XML documentation, like this:

/// <summary>  
/// I seem to have written a method to do a thing.
/// </summary>  
/// <exception cref="System.Exception">An unfortunate failure.</exception>
public void DoSomething()
{
   /* ... */
}

Answer 6

I think redgate have some a tool for this "Exception Hunter" They charge for it after a trial.

http://www.red-gate.com/products/Exception_Hunter/index.htm

Answer 7

There is a reflector add in Exception Finder which will show what exceptions could be thrown by a method. I haven't used it but saw an example of it at a .Net users group meeting.

Answer 8

There is a tool out there that can do this. You could download the trial and see if you like it. I don't really think it would be that necessary, but if you are working for a company and they'll pay for it you might want to look into it. Like has been said before there are just too many possible exceptions that be raised. Check out Excpetion Hunter

Answer 9

I find it much more frustrating to break inside an outer catch block and dig my way down to the actual point where the exception happend.

Most of the time if an exception was thrown and I didn't expect it I found a bug and it's easier to solve it if it wasn't obfuscated by some doing-nothing exception handling.

EDIT: Since your examples is actually a good one I'm still not convinced that such a tool would help you. There would be so many possible exceptions that literally every line of code could throw that you would have a hard time to find the "interesting" ones.

Answer 10

As others have said, I'm not sure if you'll find a foolproof way of doing this in C# since doesn't support checked exceptions.

As a bit of an aside, this reminded me of an interview with Anders Hejlsberg discussing "The trouble with Checked Exceptions". I'm not trying to flame checked exceptions, but suggesting that you read Ander's rationale behind C#'s exception design and the suggested way for handling exceptions: centralized exception handling.

Answer 11

Any code could potentially cause an exception it is your job to try and anticipate this!

There are a number of third party tools that may assist with finding some common errors e.g fxcop and tools such as refactor can make suggestions.

There is some work been done at the moment that can assist you with finding potential exceptions. Take a look into PEX which can help generate tests for your functions: research.microsoft.com/en-us/projects/Pex/ (link seems to be down at time of posting)

Another exciting area is code contracts (coming in .net 4/available as spec#). Code contracts allow you to write statements that specify conditions that must be met. These can be prior to and after your function being called and you can also declare invariants. A condition might be something as simple as value != null. These conditions are then analyzed at compile and runtime to check no code paths violate them.

Answer 12

Exception Hunter mentioned by a few people is a good tool to help with this. I do not know whether it has a tie-in with the <exception> XML-Doc comment so that you can enforce documentation of exceptions thrown by code.

Answer 13

As the others have said, you should assume that every single line of code can throw an exception, unless you've proven that it cannot. The better question is, "what do you plan to do about that?"

In general, you should not be catching any exceptions at all.

Of course, everything else is an exception to that rule. It makes sense to catch an exception in order to log it (if your environment doesn't do that for you, as ASP.NET does). It makes sense to catch an exception in order to replace it with another exception that provides more detail about the context:

public int GetConfiguredInteger(string name) {
    string s = null;
    try {
        s = GetStringFromConfigFile(name);
    }
    catch (IOException ex) {
        throw new Exception(String.Format(
            "Error in configuration file foo.config when processing {0}", name),
            ex);
    }
    return int.Parse(s);
}

The caller couldn't have known that the IOException was caused by a config file if you hadn't told them. Note also how I ignored all exceptions not related to the file I/O. In particular, note that the int.Parse is not even inside of the try/catch block.

There are a small number of other such exceptions, but the basic idea of catching exceptions is: don't do it unless it would be worse if you didn't.