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]]

On Apr 15, 6:12*am, paul <[e-mail]:

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]

On Apr 15, 11:39*pm, Marc Gravell <[e-mail]:

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,

[Peter Duniho]

On Tue, 15 Apr 2008 14:01:47 -0700, paul <pa**@bobbob.netwrote:

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.

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.

Also Red-Gate Exception hunter validates your code and highlights all
possible exceptions (part from generic exception).

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

[paul]

On Apr 16, 7:12*am, "Peter Duniho" <[e-mail]>
wrote:

On Tue, 15 Apr 2008 14:01:47 -0700, paul <[e-mail]:

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.

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.

Also Red-Gate Exception hunter validates your code and highlights all
possible exceptions (part from generic exception).

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

[Peter Duniho]

On Tue, 15 Apr 2008 17:32:48 -0700, paul <pa**@bobbob.netwrote:

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.

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

[paul]

On Apr 16, 11:08*am, "Peter Duniho" <[e-mail]>
wrote:

On Tue, 15 Apr 2008 17:32:48 -0700, paul <[e-mail]:

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.

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,

[Peter Duniho]

On Tue, 15 Apr 2008 19:34:53 -0700, paul <pa**@bobbob.netwrote:

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

What do you mean by "get"? I mean, you can hover your mouse over the
method name in VS. That will get you the information that's in the
documentation. You could use the "Red-Gate" tool you mentioned earlier to
do a code analysis, extracting what information it can from the code
itself.

At what point are you trying to "get" this information? How do you expect
to use it?

Pete

[henon]

On Apr 16, 4:34 am, paul <[e-mail]:

On Apr 16, 11:08 am, "Peter Duniho" <[e-mail]>
wrote:

On Tue, 15 Apr 2008 17:32:48 -0700, paul <[e-mail]:

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.

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,

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