Way to automatically see which functions can poten

Question

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

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 2

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 3

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 4

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 5

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.

Answer 6

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.