Exceptions

[Drew]

How do I know which exceptions are thrown by certain methods?

For example, reading a file might throw an IO Exception, etc.

In Java, the compiler won't even let you compile unless you put your
code in try/catch blocks but the C# compiler doesn't seem to mind?

I am particularly interested in what Exceptions are thrown by
HttpWebResponse .

Is there any easy way to figure this out without rummaging through
the API everytime?

Thanks,

Drew

[Rob Teixeira [MVP]]

The Java feature is called "checked exceptions" and C# doesn't have it.
I used to have a link from the C# developers about why they decided not to
include this feature, but I have misplaced. However, the decision was based
on this article by Bruce Eckle
http://www.mindview.net/Etc/Discussi...ckedExceptions
I tend to agree with Bruce here. I used to hold his C++ books in high
regards, and I taught Java using his Thinking In Java book.

If you want to know what exceptions are specifically thrown by a class, you
can look up the MSDN class reference for the class. You can also document
your own exceptions from your class by including it in the xml docs. Dynamic
help should help you avoid having to look all over the place for it. Since
the data is in the XML docs (or should be), it would be a nice IDE feature
to hit a button and "include catch block for..." , which would add templates
for all the ones it could discover. Going to have to wait for that feature
though. But even that's of limited use since you might want to group catch
blocks, or use more generic ones.

-Rob Teixeira [MVP]

"Drew" <so*****@hotmai l.com> wrote in message
news:el******** ******@TK2MSFTN GP12.phx.gbl...

How do I know which exceptions are thrown by certain methods?

For example, reading a file might throw an IO Exception, etc.

In Java, the compiler won't even let you compile unless you put your
code in try/catch blocks but the C# compiler doesn't seem to mind?

I am particularly interested in what Exceptions are thrown by
HttpWebResponse .

Is there any easy way to figure this out without rummaging through
the API everytime?

Thanks,

Drew

[Drew]

This is a very interesting discussion about checked exceptions.

I guess I just always took checked exceptions for granted in Java.
There are many times when I lazily just caught the exception and didn't do
much with it.

Now I'm thinking it might not be so bad without them. ;)

However, I do like your suggestion about the IDE having the capability
to generate the try/catch blocks. At the least, I would like it to show me
what exceptions are generated by a certain class. Perhaps in properties?

Drew


"Rob Teixeira [MVP]" <RobTeixeira@@m sn.com> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...

The Java feature is called "checked exceptions" and C# doesn't have it.
I used to have a link from the C# developers about why they decided not to
include this feature, but I have misplaced. However, the decision was based on this article by Bruce Eckle
http://www.mindview.net/Etc/Discussi...ckedExceptions
I tend to agree with Bruce here. I used to hold his C++ books in high
regards, and I taught Java using his Thinking In Java book.

If you want to know what exceptions are specifically thrown by a class, you can look up the MSDN class reference for the class. You can also document
your own exceptions from your class by including it in the xml docs. Dynamic help should help you avoid having to look all over the place for it. Since
the data is in the XML docs (or should be), it would be a nice IDE feature
to hit a button and "include catch block for..." , which would add templates for all the ones it could discover. Going to have to wait for that feature
though. But even that's of limited use since you might want to group catch
blocks, or use more generic ones.

-Rob Teixeira [MVP]

"Drew" <so*****@hotmai l.com> wrote in message
news:el******** ******@TK2MSFTN GP12.phx.gbl...

How do I know which exceptions are thrown by certain methods?

For example, reading a file might throw an IO Exception, etc.

In Java, the compiler won't even let you compile unless you put your
code in try/catch blocks but the C# compiler doesn't seem to mind?

I am particularly interested in what Exceptions are thrown by
HttpWebResponse .

Is there any easy way to figure this out without rummaging through
the API everytime?

Thanks,

Drew

[Tom Carter]

Hi all,

With VS.NET IDE you can use Ctrl+Alt+E (cor click the Exceptions..
line on the debug menu)when you have an open project to list all of
the exceptions that a system can throw (organized by platform and then
library). This can be followed up with a specific search of the MSDN
to isolate the actual exception details.

~~~~~~~~~~~~~
Tommie Carter
--
"Drew" <so*****@hotmai l.com> wrote in message news:<Ok******* *******@TK2MSFT NGP09.phx.gbl>. ..

This is a very interesting discussion about checked exceptions.

I guess I just always took checked exceptions for granted in Java.
There are many times when I lazily just caught the exception and didn't do
much with it.

Now I'm thinking it might not be so bad without them. ;)

However, I do like your suggestion about the IDE having the capability
to generate the try/catch blocks. At the least, I would like it to show me
what exceptions are generated by a certain class. Perhaps in properties?

Drew


"Rob Teixeira [MVP]" <RobTeixeira@@m sn.com> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...

The Java feature is called "checked exceptions" and C# doesn't have it.
I used to have a link from the C# developers about why they decided not to
include this feature, but I have misplaced. However, the decision was

based

on this article by Bruce Eckle
http://www.mindview.net/Etc/Discussi...ckedExceptions
I tend to agree with Bruce here. I used to hold his C++ books in high
regards, and I taught Java using his Thinking In Java book.

If you want to know what exceptions are specifically thrown by a class,

you

can look up the MSDN class reference for the class. You can also document
your own exceptions from your class by including it in the xml docs.

Dynamic

help should help you avoid having to look all over the place for it. Since
the data is in the XML docs (or should be), it would be a nice IDE feature
to hit a button and "include catch block for..." , which would add

templates

for all the ones it could discover. Going to have to wait for that feature
though. But even that's of limited use since you might want to group catch
blocks, or use more generic ones.

-Rob Teixeira [MVP]

"Drew" <so*****@hotmai l.com> wrote in message
news:el******** ******@TK2MSFTN GP12.phx.gbl...

How do I know which exceptions are thrown by certain methods?

For example, reading a file might throw an IO Exception, etc.

In Java, the compiler won't even let you compile unless you put your
code in try/catch blocks but the C# compiler doesn't seem to mind?

I am particularly interested in what Exceptions are thrown by
HttpWebResponse .

Is there any easy way to figure this out without rummaging through
the API everytime?

Thanks,

Drew

[Dave]

reL IDE support for exceptions...Th at would be a great feature and it has
been asked for many times, but it will probably be a long time before we see
it (lots of practical details that have not been ironed out). For now we
have to rely on the written documentation and the problem is that this is
often misleading. It may be that a given method itself only throws a small
number of exceptions, but the API you call can invoke other methods that
throw entirely different exceptions, so you may wind up catching exceptions
that are not included in the official documentation. Make sure you have a
backstop catch handler somewhere, and hooking the unhandled exception event
is also usually a good idea; you can't recover from the exception here but
you can at least log it.

"Drew" <so*****@hotmai l.com> wrote in message
news:Ok******** ******@TK2MSFTN GP09.phx.gbl...

This is a very interesting discussion about checked exceptions.

I guess I just always took checked exceptions for granted in Java.
There are many times when I lazily just caught the exception and didn't do
much with it.

Now I'm thinking it might not be so bad without them. ;)

However, I do like your suggestion about the IDE having the capability
to generate the try/catch blocks. At the least, I would like it to show me what exceptions are generated by a certain class. Perhaps in properties?

Drew


"Rob Teixeira [MVP]" <RobTeixeira@@m sn.com> wrote in message
news:eu******** ******@TK2MSFTN GP09.phx.gbl...

The Java feature is called "checked exceptions" and C# doesn't have it.
I used to have a link from the C# developers about why they decided not to include this feature, but I have misplaced. However, the decision was

based

on this article by Bruce Eckle
http://www.mindview.net/Etc/Discussi...ckedExceptions
I tend to agree with Bruce here. I used to hold his C++ books in high
regards, and I taught Java using his Thinking In Java book.

If you want to know what exceptions are specifically thrown by a class,

you

can look up the MSDN class reference for the class. You can also document your own exceptions from your class by including it in the xml docs.

Dynamic

help should help you avoid having to look all over the place for it. Since the data is in the XML docs (or should be), it would be a nice IDE feature to hit a button and "include catch block for..." , which would add

templates

for all the ones it could discover. Going to have to wait for that feature though. But even that's of limited use since you might want to group catch blocks, or use more generic ones.

-Rob Teixeira [MVP]

"Drew" <so*****@hotmai l.com> wrote in message
news:el******** ******@TK2MSFTN GP12.phx.gbl...

How do I know which exceptions are thrown by certain methods?

For example, reading a file might throw an IO Exception, etc.

In Java, the compiler won't even let you compile unless you put your
code in try/catch blocks but the C# compiler doesn't seem to mind?

I am particularly interested in what Exceptions are thrown by
HttpWebResponse .

Is there any easy way to figure this out without rummaging through
the API everytime?

Thanks,

Drew

[Rob Teixeira [MVP]]

That's really the biggest problem with the IDE auto-generating catch
statements - it doesn't know HOW you want to handle them.
For example, you may choose to group all possible ApplicationExce ptions (all
exceptions derived from ApplicationExce ption) in one block, and all generic
Exceptions in another, or you might want to handle all ApplicationExce ptions
in one block, while handling other individual exceptions in their own
blocks. The permutations and sometimes possible number of exceptions is why
i mentioned in my post that a feature like this is of somewhat limited use.

-Rob Teixeira [MVP]
"Dave" <no************ ****@wi.rr.com> wrote in message
news:um******** ******@TK2MSFTN GP10.phx.gbl...

reL IDE support for exceptions...Th at would be a great feature and it has
been asked for many times, but it will probably be a long time before we see it (lots of practical details that have not been ironed out). For now we
have to rely on the written documentation and the problem is that this is
often misleading. It may be that a given method itself only throws a small
number of exceptions, but the API you call can invoke other methods that
throw entirely different exceptions, so you may wind up catching exceptions that are not included in the official documentation. Make sure you have a
backstop catch handler somewhere, and hooking the unhandled exception event is also usually a good idea; you can't recover from the exception here but
you can at least log it.

[Drew]

How about a compile time option that would show which methods
throw exceptions and it could possibly warn you about potential
problems without requiring you to implement exception handling?

Perhaps you could select what types of warnings you want.
(e.g. checkbox: warn me about unhandled I/O exceptions, etc.)

Does this already exist?

Drew

"Rob Teixeira [MVP]" <RobTeixeira@@m sn.com> wrote in message
news:uC******** ******@tk2msftn gp13.phx.gbl...

That's really the biggest problem with the IDE auto-generating catch
statements - it doesn't know HOW you want to handle them.
For example, you may choose to group all possible ApplicationExce ptions (all exceptions derived from ApplicationExce ption) in one block, and all generic Exceptions in another, or you might want to handle all ApplicationExce ptions in one block, while handling other individual exceptions in their own
blocks. The permutations and sometimes possible number of exceptions is why i mentioned in my post that a feature like this is of somewhat limited use.
-Rob Teixeira [MVP]
"Dave" <no************ ****@wi.rr.com> wrote in message
news:um******** ******@TK2MSFTN GP10.phx.gbl...

reL IDE support for exceptions...Th at would be a great feature and it has been asked for many times, but it will probably be a long time before we

see

it (lots of practical details that have not been ironed out). For now we
have to rely on the written documentation and the problem is that this is often misleading. It may be that a given method itself only throws a small number of exceptions, but the API you call can invoke other methods that
throw entirely different exceptions, so you may wind up catching

exceptions

that are not included in the official documentation. Make sure you have a backstop catch handler somewhere, and hooking the unhandled exception

event

is also usually a good idea; you can't recover from the exception here but you can at least log it.

[David]

On 2004-01-02, Tom Carter <tc********@hot mail.com> wrote:

Hi all,

With VS.NET IDE you can use Ctrl+Alt+E (cor click the Exceptions..
line on the debug menu)when you have an open project to list all of
the exceptions that a system can throw (organized by platform and then
library). This can be followed up with a specific search of the MSDN
to isolate the actual exception details.

That's fairly useless though, if you're wonder about what exceptions
may be thrown by a particular method of a particular class.
--
David
dfoster at
hotpop dot com

[David]

On 2004-01-02, Rob Teixeira [MVP] <RobTeixeira@ @> wrote:

That's really the biggest problem with the IDE auto-generating catch
statements - it doesn't know HOW you want to handle them. For
example, you may choose to group all possible ApplicationExce ptions
(all exceptions derived from ApplicationExce ption) in one block, and
all generic Exceptions in another, or you might want to handle all
ApplicationExce ptions in one block, while handling other individual
exceptions in their own blocks. The permutations and sometimes
possible number of exceptions is why i mentioned in my post that a
feature like this is of somewhat limited use.

Just my two cents, but I think it would be very useful. For example,
click on a function, hit ctrl-alt-whatever, and up pops a tree-view
dialog box with all the exceptions that might be thrown by that function
or any functions it calls, organized by class structure. For version
two, select any node in the tree and click the 'Create catch block'
button to add the catch block.

But the "generate catch block" is secondary, the main thing is that it
would be nice to KNOW what exceptions might be thrown at a given time,
rather than just guessing, which is all you're really doing by relying
on the documentation. I agree with Eckel et. al. about the problems
with Checked Exceptions, but I wonder if there isn't a useful middle
ground, where thrown exceptions are specified somehow (for example, with
attributes in the metadata) but aren't required to be caught by the
caller. That at least would allow the IDE and compiler to provide
better support for them.
--
David
dfoster at
hotpop dot com

[Drew]

> Just my two cents, but I think it would be very useful. For example,

click on a function, hit ctrl-alt-whatever, and up pops a tree-view
dialog box with all the exceptions that might be thrown by that function
or any functions it calls, organized by class structure.

I agree. This would be very useful.

I don't think we necessarily need an auto generate feature, but just being
able to see what exceptions might be thrown would be a big help to me.

Drew