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
Everything can throw an exception. Check MSDN for a list of exceptions that can be thrown by a method.
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:
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
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
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.
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.