A way to automatically see which functions can potentially throw an exception in C #

Question

nothing more disappointing than to see how your code crashed in the debugger on a method that was excluded, and you did not try to catch it.

Is there an easy way to scan through your sources and flag all functions that could potentially throw exceptions?

Does the built-in visual help have a hidden parameter for the color of these functions in a specific color?

thanks

R

Answer 1

I think redgate has a tool for this "Exception Hunter", They accuse him of a lawsuit.

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

Answer 2

All code, but the most trivial one, can throw exceptions (at least from memory). You should probably protect your code, at least the global try / catch, rather than try at the micro level which sections of the code will or will not throw exceptions.

Answer 3

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

• Consideration of implicitly thrown exceptions, such as a StackOverflowException, can be thrown at any time from any method. You must assume that any method in the CLR may raise these types of exceptions.
• Reflection and / or delegates can hide the actual code that is called in a particular method, so you cannot check all the possible code paths of a method.
• This will require validation of the IL metadata.
• There is no requirement in .Net to document exceptions explicitly specified by the API

Answer 4

As others have said, I'm not sure that you will find a reliable way to do this in C #, since it does not support checked exceptions.

As a little aside, it reminded me of an interview with Anders Heilsberg, which discussed the " Problem with checked exceptions ." I'm not trying to check for exceptions, but I assume that you are reading Ander’s rationale behind the C # exception design and the proposed method for handling exceptions: centralized exception handling.

Answer 5

I think resharper gives you hints about exceptions. But because C # does not support checked exceptions, there is a way to define exceptions. Perhaps code analysis tools like NDepend support this.

Answer 6

Anything can throw an exception. Check the MSDN for a list of exceptions that can be selected by the method.

Answer 7

All non-empty methods can throw exceptions in one form or another. If you are worried about exceptions that you personally created, you can display them from intellisense in the same way as infrastructure methods using XML documentation, for example:

/// <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 8

Any code could potentially throw an exception, it's your job to try to anticipate this!

There are a number of third-party tools that can help you find some common mistakes, for example, fxcop, and tools like refactoring can make suggestions.

At the moment, some work has been done that will help you find possible exceptions. Take a look at PEX to help generate tests for your functions: research.microsoft.com/en-us/projects/Pex/ (the link does not seem to work at the time of publication)

Another interesting area is code contracts (included in .net 4 / available as spe #). Code contracts allow you to write statements that define the conditions that must be met. They can be before and after calling your function, and you can also declare invariants. The condition may be something simple, like the value! = Null. These conditions are then analyzed at compilation and runtime to see if their code violates.

Answer 9

As others have said, you should assume that every line of code can throw an exception if you have not proven that this is not possible. The best question is: "What are you planning to do about this?"

In general, you should not catch any exceptions at all.

Of course, everything else is an exception to this rule. It makes sense to catch an exception to register it (if your environment does not do this for you, as ASP.NET does). It makes sense to catch an exception to replace it with another exception that provides more detailed information 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 could not know that an IOException was thrown by the configuration file unless you told them. Also notice how I ignored all exceptions not related to file I / O. In particular, note that int.Parse is not even inside a try / catch block.

There are a small number of other exceptions, but the main idea for catching exceptions is this: do not do this if it will not be worse if you did not.

Answer 10

The reflector has an Exception Finder , which will show which exceptions can be selected by the method. I did not use it, but saw it at a .Net user group meeting.

Answer 11

There is a tool that can do this. You can download a trial version and see if you like it. I really don’t think it would be necessary, but if you work in a company and they will pay for it, you may want to look into it. As stated earlier, there are too many possible exceptions that arise. Check out the food hunter

Answer 12

I find it much more unpleasant to break inside an external catch block and delve into the actual point at which the exception occurred.

In most cases, if an exception was thrown, and I did not expect to find an error, and it is easier to solve if it was not confused by handling the exceptions without any operations.

EDIT: Since your examples are actually good, I'm still not convinced that such a tool will help you. There would be so many possible exceptions that literally every line of code could throw that it would be difficult for you to find "interesting" ones.

Answer 13

The exception hunter mentioned by several people is a good tool for this. I don’t know if it has an XML-Doc <exception> comment so that you can document exceptions thrown by the code.