MSDN Exception Documentation

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Where can I look in the MSDN to find documentation on what exceptions a class
might throw? Looking at the class and method descriptions, it does not seem
odvious. Google is not much help either.
Thank you, Ryan
 
Autocomplete will show you what exceptions are defined in the class, but it
could throw anything, and may simply pass back or rethrow any exception it
encounters itself, so I don't think there can be a definitive list.
 
PIEBALD said:
Autocomplete will show you what exceptions are defined in the class, but it
could throw anything, and may simply pass back or rethrow any exception it
encounters itself, so I don't think there can be a definitive list.
Click to expand...

Java has the "throws" keyword which allows the compiler to figure this out.
Is there no analog in .Net?
 
No there isn't. This was a deliberate choice. I know they looked at putting
a "throws" keyword in, but after analyzing the problems it caused and the
value that it added, they decided that it wasn't worthwhile. However, if I
look at MSDN documentation, quite a few method calls indicate what
exceptions they throw in their documentation. Since this is not mandated by
a throws keyword, but is merely documentation, the exceptions given may be
different from those actually thrown.
 
Well, without any way to difinitivly know what exceptions the framework may
throw, how do I effectively code my exception handlers? Do I just wrap every
API call in a try/catch and catch the generic Exception? Without some sort of
compiler support, this seems like it could be the source of endless errors,
some of which we are already feeling in my shop.
 
API calls? They're not managed so don't even throw "exceptions", you need an
"empty" catch for those.

What you want is unknowable, it can't be done with any reliability.
 
Swallowing exceptions on every call is one of the things that the C#
designers were trying to avoid when they decided to leave out checked
exceptions. You code you exception handlers by having a look at the
documentation for the call, seeing if any exceptions are documented, if they
are, then deciding whether you would be able to handle that error in that
place. If not, you leave off the exception handler, and allow code higher up
the call stack to handle it. Further exception handlers would be added
during debugging. Obviously try..finally or using blocks around expensive
resources.

If you are not aware of what exception a call can raise, then there's no way
you can handle it effectively. In that case, no catch blocks.

When you say API calls, are you referring to the core Windows API, or to the
BCL? Windows API calls do not throw exceptions (as piebald said), if they
have the PreserveSig attribute defined on them in the interop declaration.
 
Sean Hederman said:
Swallowing exceptions on every call is one of the things that the C#
designers were trying to avoid when they decided to leave out checked
exceptions. You code you exception handlers by having a look at the
documentation for the call, seeing if any exceptions are documented, if they
are, then deciding whether you would be able to handle that error in that
place. If not, you leave off the exception handler, and allow code higher up
the call stack to handle it.
Click to expand...

And you can do all of that with checked exceptions too - it's just the
compiler forces you to do it, and doesn't rely on the docs being
correct. All you do is add a "throws" clause to the method declaration
if you can't handle the exception.

Personally, I've seen more "catch everything because I don't know what
to catch" blocks in C# than I have in Java. YMMV.
 
Jon Skeet said:
And you can do all of that with checked exceptions too - it's just the
compiler forces you to do it, and doesn't rely on the docs being
correct. All you do is add a "throws" clause to the method declaration
if you can't handle the exception.
Click to expand...

Very true, but also consider the scenario where you're calling three
different methods inside your method, each of which throws three different
exceptions. If you don't want to handle the exceptions in that method,
you're going to have a very long throws clause. Alternatively you'd just say
throws Exception, but that sort of defeats the purpose of the throws
statement.

Plus, if the API writers go along and adds an exception to the throws clause
of a method buried deep in their object hierarchy, the API consumer is going
to be working like mad to update all their code to handle the new exception
type, adding throws clauses, or adding catch statements, or changing the
throws/catches to Exception...
 
Sean Hederman said:
Very true, but also consider the scenario where you're calling three
different methods inside your method, each of which throws three different
exceptions. If you don't want to handle the exceptions in that method,
you're going to have a very long throws clause. Alternatively you'd just say
throws Exception, but that sort of defeats the purpose of the throws
statement.
Click to expand...

Yes, if those each throw three different exception types, you end up
having to write a throws statement which has nine exceptions in.
Personally, I think that's actually good - it forces the developer to
think of all nine exceptions. Think about the same thing in .NET - can
you honestly say you'd always think about all nine, rather than missing
one?
Plus, if the API writers go along and adds an exception to the throws clause
of a method buried deep in their object hierarchy, the API consumer is going
to be working like mad to update all their code to handle the new exception
type, adding throws clauses, or adding catch statements, or changing the
throws/catches to Exception...
Click to expand...

Whereas without even the option of checked exceptions, that extra
exception is only added to the documentation, and the API consumer may
well not even notice...
 
Hmm, good points. I won't say you've convinced me, but the ship is starting
to turn...

It'd be really nice if there was an FxCop rule that did a code analysis for
exception throws and catches. You could create a couple of custom attributes
to handle scenarios such as when an exception object is created via
Reflection. That would allow those who want to use a throws-like scheme to
switch on that FxCop rule.
 
Back
Top