How to extract all exceptions for any method

[paul]

Hi

I would like to extract all possible exceptions for a particular
method. Ideally this would be a Visual Studio 2005 Add-In and would
allow a developer to highlight a any method, pressing a shortcut key
which would result in a try/catch with all exception(s) handled.

Would someone nice out there help me on this one as this process gets
ignored by my team because it takes took long.

Regards,
Paul

 

[Marc Gravell]

Unlike java, C# doesn't enforce specific exception handling. You can
add notes that an exception might be expected, but you can get many
more at any time (OutOfMemoryException, SecurityException [principal],
ThreadAbortException, etc).

To indicate specific expected exceptions, use /// comments:

/// <exception cref="FooException">Throws a Foo when you Bar</
exception>

Still! In most cases, exception handling is limited to rolling back
any damage, perhaps logging, and re-throwing. In my experience, it is
very rare that there are *lots* of expected exceptions with different
handling strategies - generally I might expect one or two special
cases, and let the rest just raise through the stack (with higher-up
code worrying about it)... and you can handle the one-or-two easily
enough from comments.

Additionally, constructs like "using" and "lock" can be used to ensure
that resources are released cleanly upon exit (even through
exception).

Did you have a specific scenario in mind?

Marc

 

[Jon Skeet [C# MVP]]

I would like to extract all possible exceptions for a particular
method.  Ideally this would be a Visual Studio 2005 Add-In and would
allow a developer to highlight a any method, pressing a shortcut key
which would result in a try/catch with all exception(s) handled.

There's no way of doing this, because there's no way of reliably
predicting what exceptions a method could throw. For instance, there
are a bunch of exceptions which can occur at any time (threads being
aborted, app domains being unloaded, out of memory) and even if you
recursively try to work out which exceptions a method throws directly,
and which exceptions are thrown by methods that original method calls
(etc) it would turn into an unworkable nightmare very quickly.

Would someone nice out there help me on this one as this process gets
ignored by my team because it takes took long.

It sounds like you're regularly trying to catch everything, which is
usually a bad idea. Generally, you should have far more try/finally
blocks (usually in the form of "using" statements) than try/catch
blocks.

Only catch exceptions you're actually able to handle, unless you're
pretty much at the top of a thread, where you *might* (depending on
context) want to catch everything and react appropriately (e.g.
logging before quitting, or aborting that request for a server type
application).

Jon

 

[paul]

Unlike java, C# doesn't enforce specific exception handling. You can
add notes that an exception might be expected, but you can get many
more at any time (OutOfMemoryException, SecurityException [principal],
ThreadAbortException, etc).

To indicate specific expected exceptions, use /// comments:

/// <exception cref="FooException">Throws a Foo when you Bar</
exception>

Still! In most cases, exception handling is limited to rolling back
any damage, perhaps logging, and re-throwing. In my experience, it is
very rare that there are *lots* of expected exceptions with different
handling strategies - generally I might expect one or two special
cases, and let the rest just raise through the stack (with higher-up
code worrying about it)... and you can handle the one-or-two easily
enough from comments.

Additionally, constructs like "using" and "lock" can be used to ensure
that resources are released cleanly upon exit (even through
exception).

Did you have a specific scenario in mind?

Marc

Hi

Thank you for the info.

I am pretty sure this can be done as Visual Studio 2005 already tells
you the specific Exceptions that can be generated by a single method.
Also Red-Gate Exception hunter validates your code and highlights all
possible exceptions (part from generic exception).

For example:

Old code:

File.Open(..);

Would in a result like this

try
{
File.Open(..);
}
Catch (FileNotFoundException ex)
{
..
}
Catch (DirectoryNotFound ex)
{
...
}
Catch (Exception ex)
{
...
}

Regards,

 

[paul]

I'm not aware of any feature in VS that does this generally.  It's true  
that the documentation for much of .NET includes information as to which  
exceptions may be thrown, and inasmuch as VS shows you that documentation, 
it will show you those specific exceptions.

If you know of something more specific than that, perhaps you could  
provide more details regarding what you're seeing in VS.


I'm not familiar with that tool.  However, it's plainly false that it  
"highlights all possible exceptions".  No doubt it does a good job  
traversing the call chain (something that's easily done via reflection),  
looking for code that creates and throws exceptions.  But it's simply not  
possible to find literally all possible exceptions.

As Marc already asked, was there some specific situation or scenario  
you're trying to address?  Generally speaking, if it's possible for a  
method to throw some exception that can be usefully dealt with, it will be 
documented by the author of that method.  Other kinds of exceptions that 
might be thrown wouldn't be relevant information anyway, by definition.

Pete

Hi

This is possible and it's standard in VS Studio 2005 (C#).

Hover your mouse over a method (e.g. System.IO.File.Open) and wait for
the little popup window, here lists all known exceptions (again part
from generic exceptions), so it is possible.

Paul

 

[paul]

Yup.  That's part of the documentation.  It exists only because the author  
of the class (in this case, Microsoft) included that information.  It  
doesn't do it for any random method, and it doesn't show you literally  
every exception that could be thrown.

Pete

OK, so how can I get this information (and I am not expecting that
every single method will have this).

Regards,

 

[henon]

OK, so how can I get this information (and I am not expecting that
every single method will have this).

Regards,

you could "get" the info from the xml file where the documentation for
a specific assembly can be found.
-- Henon