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*****@hotmail.com> wrote in message
news:el**************@TK2MSFTNGP12.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@@msn.com> wrote in message
news:eu**************@TK2MSFTNGP09.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*****@hotmail.com> wrote in message
news:el**************@TK2MSFTNGP12.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*****@hotmail.com> wrote in message news:<Ok**************@TK2MSFTNGP09.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@@msn.com> wrote in message
news:eu**************@TK2MSFTNGP09.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*****@hotmail.com> wrote in message
news:el**************@TK2MSFTNGP12.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...That 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*****@hotmail.com> wrote in message
news:Ok**************@TK2MSFTNGP09.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@@msn.com> wrote in message
news:eu**************@TK2MSFTNGP09.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*****@hotmail.com> wrote in message
news:el**************@TK2MSFTNGP12.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 ApplicationExceptions (all
exceptions derived from ApplicationException) in one block, and all generic
Exceptions in another, or you might want to handle all ApplicationExceptions
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**************@TK2MSFTNGP10.phx.gbl...

reL IDE support for exceptions...That 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@@msn.com> wrote in message
news:uC**************@tk2msftngp13.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 ApplicationExceptions (all exceptions derived from ApplicationException) in one block, and all generic Exceptions in another, or you might want to handle all ApplicationExceptions 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**************@TK2MSFTNGP10.phx.gbl...

reL IDE support for exceptions...That 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********@hotmail.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 ApplicationExceptions
(all exceptions derived from ApplicationException) in one block, and
all generic Exceptions in another, or you might want to handle all
ApplicationExceptions 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

[Dave]

I disagree. The main task of the IDE would be to generate a skeleton catch
handler for the particular exception you wanted to handle; it could ask for
each type you wanted. The details of how you implement the handler are
yours.

The primary rule the IDE needs to follow for autogenerating catch blocks is
that it puts the most specific exception type first followed by less
specific types. In other words, put the most derived exception classes first
and the base classes last. When the CLR evaluates the type-filtered catch
clauses it invokes the first handler that satisfies the type matching.

However, all this is moot since this feature does not exist in the IDE and
probably wont anytime soon. The current state of the art requires that we do
this manually.

The subject of how to best implement catch handlers (and when to throw) is
actually far more complex then this - this is just scratching the surface.
There is no consensus on where the catch block should be, which exceptions
should be caught, which allowed to bubble up the call stack, how to
categorize exceptions (e.g. between technical and data/business logic), etc.

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:uC**************@tk2msftngp13.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 ApplicationExceptions (all exceptions derived from ApplicationException) in one block, and all generic Exceptions in another, or you might want to handle all ApplicationExceptions 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]

[Rob Teixeira [MVP]]

> The subject of how to best implement catch handlers (and when to throw) is

actually far more complex then this - this is just scratching the surface.
There is no consensus on where the catch block should be, which exceptions
should be caught, which allowed to bubble up the call stack, how to
categorize exceptions (e.g. between technical and data/business logic), etc.

This is the crux of my statement. And you're mirroring my sentiments exactly
when you say that this is only scratching the surface. That's why I believe
that having the IDE auto-generate the catch statements is of limited use. It
isn't just a matter, as you say in the first paragraph, of the details of
the implementation of the handler being left up to you (the programmer), but
the entire structure and grouping of the exceptions is also an issue. For
example, let's say a particular method throws a potential of seven custom
exception instances and all of those exception types inherit from
ApplicationException. Knowing that ApplicationExceptions and their
derivatives indicate non-fatal app-specific problems, the programmer chooses
to simply display a message box with the localized exception message and a
statement that the operation cannot be completed. In a scenario where the
IDE generates all seven catch statements (for just this one method), the
programmer would just end up deleting all seven blocks and writing a block
that catches ApplicationException anyway. This also doesn't account for the
fact that this feature doesn't tell the programmer that those exceptions
inherited ApplicationException in the first place.

On the other hand, if all you want (as has been posted here by several
people) is a simple list of exceptions thrown by a method, that is
acheivable. The XML docs allow for an <exception> tag. So, as long as the
classes and methods are DOCUMENTED (emphesis for people who don't like to
document their code! :-) ) it is easy for anyone to build an IDE add-in that
can look this information up. The add-in can provide a table of exceptions
and even drill into the document for the specific type exception class via a
link (this tag allows a "cref" attribute back to the exception class
itself). Nice pet project if anyone wants to take it up.

-Rob Teixeira [MVP]

"Dave" <no****************@wi.rr.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... I disagree. The main task of the IDE would be to generate a skeleton catch
handler for the particular exception you wanted to handle; it could ask for each type you wanted. The details of how you implement the handler are
yours.

The primary rule the IDE needs to follow for autogenerating catch blocks is that it puts the most specific exception type first followed by less
specific types. In other words, put the most derived exception classes first and the base classes last. When the CLR evaluates the type-filtered catch
clauses it invokes the first handler that satisfies the type matching.

However, all this is moot since this feature does not exist in the IDE and
probably wont anytime soon. The current state of the art requires that we do this manually.

The subject of how to best implement catch handlers (and when to throw) is
actually far more complex then this - this is just scratching the surface.
There is no consensus on where the catch block should be, which exceptions
should be caught, which allowed to bubble up the call stack, how to
categorize exceptions (e.g. between technical and data/business logic), etc.

[Drew]

> On the other hand, if all you want (as has been posted here by several

people) is a simple list of exceptions thrown by a method, that is
acheivable. The XML docs allow for an <exception> tag. So, as long as the
classes and methods are DOCUMENTED (emphesis for people who don't like to
document their code! :-) ) it is easy for anyone to build an IDE add-in that can look this information up. The add-in can provide a table of exceptions
and even drill into the document for the specific type exception class via a link (this tag allows a "cref" attribute back to the exception class
itself). Nice pet project if anyone wants to take it up.

Is it possible to determine the exceptions thrown by a method via
Reflection?
(I'm not really fond of the idea of having to document every class/method in
order for this to work)

Also, any thoughts on the compile time warning system I mentioned
previously?

Drew

[Daniel O'Connell]

"Drew" <so*****@hotmail.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

On the other hand, if all you want (as has been posted here by several
people) is a simple list of exceptions thrown by a method, that is
acheivable. The XML docs allow for an <exception> tag. So, as long as the classes and methods are DOCUMENTED (emphesis for people who don't like to document their code! :-) ) it is easy for anyone to build an IDE add-in that

can look this information up. The add-in can provide a table of exceptions and even drill into the document for the specific type exception class

via a

link (this tag allows a "cref" attribute back to the exception class
itself). Nice pet project if anyone wants to take it up.
Is it possible to determine the exceptions thrown by a method via
Reflection?
(I'm not really fond of the idea of having to document every class/method

in order for this to work)
No, you would have to disassemble and crawl through the methods definition.
Effectivly certain(posisbly many, I'm not sure) instructions are capable of
causing an exception(call and its variants being the most obvious, outside
of the throw instruction, but mathematic and allocation instructions can
cause exceptoins as well). To detect the capacity for exceptions, one would
have to scan the entire file(and the entire framework, at that), and build a
database of possible exceptions from any given path, and that still may not
hit upon everything. Its mostly just data processing and could be done with
an IL reader, it would just be time consuming, I suspect. Its an interesting
project, sourceforge kinda thing maybe, ;). However things like not flagging
object x = null;
if (x == null)
throw new Exception("Error!");
x.ToString();

as a potential exception generator as far as NullReference goes could be
more complicated. Also, any thoughts on the compile time warning system I mentioned
previously? Ideally, instead of compile time, I'd rather see a utility like FxCop.
Something that performs heavy analysis(perhaps as a post-build tool) and
spits out possible problems. Frankly having the compiler do the analysis
required would probably reduce the speed and seriously increase the
complexity of the compiler, whereas a seperate tool can be enabled only when
needed and should be usable by any language.
Drew

[Rob Teixeira [MVP]]

Not necessarily from reflection. You would need the XML file generated by
the XML doc feature of C#.
When you type a method, the IDE's intellisense engine reads this XML file to
figure out what to put in the tooltips.
You'll have to do a little reading up on how the XML file is structured so
you know how to find the right node based on the context of the code DOM
from the currently active code window.

But again, this depends on people actually writing the proper documentation
and including the <exception> tags. It won't cover 100% of exceptions, since
it's possible that unforseen or unhandled exceptions can fall through from
further down the call stack. But then again, not all Java exceptions are
checked exceptions either, so this is pretty much on par - and it goes to
show that it's always important to have a generic exception catch block.

-Rob Teixeira [MVP]

"Drew" <so*****@hotmail.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

Is it possible to determine the exceptions thrown by a method via
Reflection?
(I'm not really fond of the idea of having to document every class/method in order for this to work)

Also, any thoughts on the compile time warning system I mentioned
previously?

Drew

[Dave]

I believe we are in violent agreement on most issues. However, I maintain
that it would be useful and possible for the IDE to generate a skelton
outline of a catch handler that was correct, at least in terms of ordering
the handlers from most specific to least specific. That being said it would
definitely be a non-trivial task, as the IDE would have to evaluate all the
exceptions that could possibly be thrown within a given try block, present
the types in a list for someone to pick the handler they wanted generated,
etc.

I think the only way this becomes feasible is when static analysis tools
become better at evaluating the exceptions that could be thrown (e.g. a
statement throws an exception that is not handled locally so it bubbles up),
and the results are baked into each method's metadata.

I believe your concern is valid, but the structuring of exceptions (i.e. the
ordering of the handlers) is actually better done automatically as a
compiler is better-suited for evaluating object hierarchies then humans are.

What the compiler cannot do is determine which exceptions should be caught
versus allowed to bubble up, and even harder, which exceptions need
conditional testing to determine if it should bubble up. And which ones
should be swallowed and ignored, or should never be handled at all
(ExecutionEngineException, etc). Or which ones are actually part of program
flow control (this is actually bad practice but some library implementations
were poorly done and require this). And, of course, the actual handling of
the exception needs to be written and tested.

The main disagreement I have is that I do not feel it is worthwhile to use
XML as a means of documenting this. It is way too error prone and
version-dependent - if it is done by hand then it is probably going to be
wrong. I want it baked into the metadata as part of a compilation phase so
that it is always correct and up-to-date (and automatic), and when changing
assembly versions I automatically get the correct information. It also makes
it possible for intelligent code to use reflection to extract useful
exception-related information.

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

The subject of how to best implement catch handlers (and when to throw) is actually far more complex then this - this is just scratching the surface. There is no consensus on where the catch block should be, which exceptions should be caught, which allowed to bubble up the call stack, how to
categorize exceptions (e.g. between technical and data/business logic), etc.

This is the crux of my statement. And you're mirroring my sentiments

exactly when you say that this is only scratching the surface. That's why I believe that having the IDE auto-generate the catch statements is of limited use. It isn't just a matter, as you say in the first paragraph, of the details of
the implementation of the handler being left up to you (the programmer), but the entire structure and grouping of the exceptions is also an issue. For
example, let's say a particular method throws a potential of seven custom
exception instances and all of those exception types inherit from
ApplicationException. Knowing that ApplicationExceptions and their
derivatives indicate non-fatal app-specific problems, the programmer chooses to simply display a message box with the localized exception message and a
statement that the operation cannot be completed. In a scenario where the
IDE generates all seven catch statements (for just this one method), the
programmer would just end up deleting all seven blocks and writing a block
that catches ApplicationException anyway. This also doesn't account for the fact that this feature doesn't tell the programmer that those exceptions
inherited ApplicationException in the first place.

On the other hand, if all you want (as has been posted here by several
people) is a simple list of exceptions thrown by a method, that is
acheivable. The XML docs allow for an <exception> tag. So, as long as the
classes and methods are DOCUMENTED (emphesis for people who don't like to
document their code! :-) ) it is easy for anyone to build an IDE add-in that can look this information up. The add-in can provide a table of exceptions
and even drill into the document for the specific type exception class via a link (this tag allows a "cref" attribute back to the exception class
itself). Nice pet project if anyone wants to take it up.

[WoodBeeProgrammer]

Isn't this something "someone" (DevExpress? CodeObject?) could do-- a tool
which at design time would list the exceptions it could find from the XML
docs, at runtime could provide a logging object to get the ones that weren't
doc'd correctly etc-- i'd purchase something like this..
"Dave" <no****************@wi.rr.com> wrote in message
news:OR**************@TK2MSFTNGP09.phx.gbl...

I believe we are in violent agreement on most issues. However, I maintain
that it would be useful and possible for the IDE to generate a skelton
outline of a catch handler that was correct, at least in terms of ordering
the handlers from most specific to least specific. That being said it would definitely be a non-trivial task, as the IDE would have to evaluate all the exceptions that could possibly be thrown within a given try block, present the types in a list for someone to pick the handler they wanted generated,
etc.

I think the only way this becomes feasible is when static analysis tools
become better at evaluating the exceptions that could be thrown (e.g. a
statement throws an exception that is not handled locally so it bubbles up), and the results are baked into each method's metadata.

I believe your concern is valid, but the structuring of exceptions (i.e. the ordering of the handlers) is actually better done automatically as a
compiler is better-suited for evaluating object hierarchies then humans are.
What the compiler cannot do is determine which exceptions should be caught
versus allowed to bubble up, and even harder, which exceptions need
conditional testing to determine if it should bubble up. And which ones
should be swallowed and ignored, or should never be handled at all
(ExecutionEngineException, etc). Or which ones are actually part of program flow control (this is actually bad practice but some library implementations were poorly done and require this). And, of course, the actual handling of
the exception needs to be written and tested.

The main disagreement I have is that I do not feel it is worthwhile to use
XML as a means of documenting this. It is way too error prone and
version-dependent - if it is done by hand then it is probably going to be
wrong. I want it baked into the metadata as part of a compilation phase so
that it is always correct and up-to-date (and automatic), and when changing assembly versions I automatically get the correct information. It also makes it possible for intelligent code to use reflection to extract useful
exception-related information.

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

The subject of how to best implement catch handlers (and when to

throw)

is actually far more complex then this - this is just scratching the surface. There is no consensus on where the catch block should be, which exceptions should be caught, which allowed to bubble up the call stack, how to
categorize exceptions (e.g. between technical and data/business

logic), etc.

This is the crux of my statement. And you're mirroring my sentiments exactly

when you say that this is only scratching the surface. That's why I

believe

that having the IDE auto-generate the catch statements is of limited use. It

isn't just a matter, as you say in the first paragraph, of the details

of the implementation of the handler being left up to you (the programmer),

but

the entire structure and grouping of the exceptions is also an issue. For example, let's say a particular method throws a potential of seven custom exception instances and all of those exception types inherit from
ApplicationException. Knowing that ApplicationExceptions and their
derivatives indicate non-fatal app-specific problems, the programmer

chooses

to simply display a message box with the localized exception message and a statement that the operation cannot be completed. In a scenario where the IDE generates all seven catch statements (for just this one method), the
programmer would just end up deleting all seven blocks and writing a block that catches ApplicationException anyway. This also doesn't account for

the

fact that this feature doesn't tell the programmer that those exceptions
inherited ApplicationException in the first place.

On the other hand, if all you want (as has been posted here by several
people) is a simple list of exceptions thrown by a method, that is
acheivable. The XML docs allow for an <exception> tag. So, as long as the classes and methods are DOCUMENTED (emphesis for people who don't like to document their code! :-) ) it is easy for anyone to build an IDE add-in

that

can look this information up. The add-in can provide a table of exceptions and even drill into the document for the specific type exception class

via a

link (this tag allows a "cref" attribute back to the exception class
itself). Nice pet project if anyone wants to take it up.

[Brad Williams]

"Dave" wrote:

That being said it would
definitely be a non-trivial task, as the IDE would have to evaluate all the exceptions that could possibly be thrown within a given try block, ...

Is this really possible? Can't IL code be obfuscated (by tools) to the
point that you simply cannot statically evaluate which op-codes are "part
of" a given method? I don't know, just suspicious.

Brad Williams

[Rob Teixeira [MVP]]

Not going to disagree with you there. I brought up the XML doc file, not
becuase it's a good idea, but simply because it is the ONLY place the
information currently exists (if it exists at all).

However, let's look at the trade-off for such a solution now. Your programs
get much bigger (if this follows the attributes meta data design, we're
talking about serialized instances of some exception info class being
injected into the meta data for every member), and the only benefit you get
is a decent listing of exceptions (and possibly the auto-generated order,
etc). I'm not sure everyone would agree the trade-off is worthwhile. So now
you get people wanting to turn it off! Which means you will now have members
that lack exception information - which in turn brings us right back to
where we were :-)

-Rob Teixeira [MVP]

"Dave" <no****************@wi.rr.com> wrote in message
news:OR**************@TK2MSFTNGP09.phx.gbl...

The main disagreement I have is that I do not feel it is worthwhile to use
XML as a means of documenting this. It is way too error prone and
version-dependent - if it is done by hand then it is probably going to be
wrong. I want it baked into the metadata as part of a compilation phase so
that it is always correct and up-to-date (and automatic), and when changing assembly versions I automatically get the correct information. It also makes it possible for intelligent code to use reflection to extract useful
exception-related information.

[Dave]

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:ux****************@tk2msftngp13.phx.gbl...

Not going to disagree with you there. I brought up the XML doc file, not
becuase it's a good idea, but simply because it is the ONLY place the
information currently exists (if it exists at all).
Agreed. It would be a way to do it given current technology.
However, let's look at the trade-off for such a solution now. Your programs get much bigger (if this follows the attributes meta data design, we're
talking about serialized instances of some exception info class being
injected into the meta data for every member),
Sure, but that's just the size of the assembly and the metadata within it -
the actual IL should not be affected by this.
and the only benefit you get
is a decent listing of exceptions (and possibly the auto-generated order,
etc).
I think this would be an extremely powerful and useful feature. You could
easily and instantly use it as a reference into what exceptions you expect
to be thrown from within a given try block. It's more then evaluating a
method, it would have to evaluate all the methods within a try block to be
useful.
I'm not sure everyone would agree the trade-off is worthwhile. So now
you get people wanting to turn it off! Which means you will now have members that lack exception information - which in turn brings us right back to
where we were :-)

LOL! Well, if I had a telescope that could see clear across the universe all
I would see is the back of my own head but it would be an interesting
journey :-)

[Dave]

You could do it yourself, but the problem I have with relying on XML
handwritten docs is that it requires too much manual effort; and any system
that requires manual effort will eventually have bad data input into it so
it will generate incorrect results - that's worse then not doing it at all.

"WoodBeeProgrammer" <Wo***************@spamex.com> wrote in message
news:10***************@utility.isomedia.com...

Isn't this something "someone" (DevExpress? CodeObject?) could do-- a tool
which at design time would list the exceptions it could find from the XML
docs, at runtime could provide a logging object to get the ones that weren't doc'd correctly etc-- i'd purchase something like this..
"Dave" <no****************@wi.rr.com> wrote in message
news:OR**************@TK2MSFTNGP09.phx.gbl...

I believe we are in violent agreement on most issues. However, I maintain

that it would be useful and possible for the IDE to generate a skelton
outline of a catch handler that was correct, at least in terms of ordering the handlers from most specific to least specific. That being said it would

definitely be a non-trivial task, as the IDE would have to evaluate all

the

exceptions that could possibly be thrown within a given try block,

present

the types in a list for someone to pick the handler they wanted generated, etc.

I think the only way this becomes feasible is when static analysis tools
become better at evaluating the exceptions that could be thrown (e.g. a
statement throws an exception that is not handled locally so it bubbles

up),

and the results are baked into each method's metadata.

I believe your concern is valid, but the structuring of exceptions (i.e.

the

ordering of the handlers) is actually better done automatically as a
compiler is better-suited for evaluating object hierarchies then humans

are.

What the compiler cannot do is determine which exceptions should be caught versus allowed to bubble up, and even harder, which exceptions need
conditional testing to determine if it should bubble up. And which ones
should be swallowed and ignored, or should never be handled at all
(ExecutionEngineException, etc). Or which ones are actually part of

program

flow control (this is actually bad practice but some library

implementations

were poorly done and require this). And, of course, the actual handling of the exception needs to be written and tested.

The main disagreement I have is that I do not feel it is worthwhile to use XML as a means of documenting this. It is way too error prone and
version-dependent - if it is done by hand then it is probably going to be wrong. I want it baked into the metadata as part of a compilation phase so that it is always correct and up-to-date (and automatic), and when

changing

assembly versions I automatically get the correct information. It also

makes

it possible for intelligent code to use reflection to extract useful
exception-related information.

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

> The subject of how to best implement catch handlers (and when to throw)

is

> actually far more complex then this - this is just scratching the

surface.

> There is no consensus on where the catch block should be, which

exceptions

> should be caught, which allowed to bubble up the call stack, how to
> categorize exceptions (e.g. between technical and data/business

logic), etc.

This is the crux of my statement. And you're mirroring my sentiments

exactly

when you say that this is only scratching the surface. That's why I

believe

that having the IDE auto-generate the catch statements is of limited use.

It

isn't just a matter, as you say in the first paragraph, of the details

of the implementation of the handler being left up to you (the programmer), but

the entire structure and grouping of the exceptions is also an issue. For example, let's say a particular method throws a potential of seven custom exception instances and all of those exception types inherit from
ApplicationException. Knowing that ApplicationExceptions and their
derivatives indicate non-fatal app-specific problems, the programmer

chooses

to simply display a message box with the localized exception message

and a statement that the operation cannot be completed. In a scenario where the IDE generates all seven catch statements (for just this one method),

the programmer would just end up deleting all seven blocks and writing a block that catches ApplicationException anyway. This also doesn't account for the

fact that this feature doesn't tell the programmer that those

exceptions inherited ApplicationException in the first place.

On the other hand, if all you want (as has been posted here by several
people) is a simple list of exceptions thrown by a method, that is
acheivable. The XML docs allow for an <exception> tag. So, as long as the classes and methods are DOCUMENTED (emphesis for people who don't like to document their code! :-) ) it is easy for anyone to build an IDE

add-in that

can look this information up. The add-in can provide a table of

exceptions and even drill into the document for the specific type exception class

via

a

link (this tag allows a "cref" attribute back to the exception class
itself). Nice pet project if anyone wants to take it up.

[Dave]

I don't know anything about obfuscation except that I would think if it
obfuscated the actual meaning of the IL it would render it meaningless.

"Brad Williams" <sp**@wcsoft.com> wrote in message
news:O7**************@TK2MSFTNGP09.phx.gbl...

"Dave" wrote:

That being said it would
definitely be a non-trivial task, as the IDE would have to evaluate all

the

exceptions that could possibly be thrown within a given try block, ...

Is this really possible? Can't IL code be obfuscated (by tools) to the
point that you simply cannot statically evaluate which op-codes are "part
of" a given method? I don't know, just suspicious.

Brad Williams

[Daniel O'Connell]

"Dave" <no****************@wi.rr.com> wrote in message
news:eN**************@TK2MSFTNGP11.phx.gbl...

"Rob Teixeira [MVP]" <RobTeixeira@@msn.com> wrote in message
news:ux****************@tk2msftngp13.phx.gbl...

Not going to disagree with you there. I brought up the XML doc file, not
becuase it's a good idea, but simply because it is the ONLY place the
information currently exists (if it exists at all).
Agreed. It would be a way to do it given current technology.

However, let's look at the trade-off for such a solution now. Your

programs

get much bigger (if this follows the attributes meta data design, we're
talking about serialized instances of some exception info class being
injected into the meta data for every member),

Sure, but that's just the size of the assembly and the metadata within

it - the actual IL should not be affected by this.

and the only benefit you get
is a decent listing of exceptions (and possibly the auto-generated order, etc).
I think this would be an extremely powerful and useful feature. You could
easily and instantly use it as a reference into what exceptions you expect
to be thrown from within a given try block. It's more then evaluating a
method, it would have to evaluate all the methods within a try block to be
useful.

Well, the first step is to write a static tool that can analyze IL and
determine what exceptions can be thrown. This is likely to be a very
complicated piece of code and would be written best as an external(IE
not-compiler) application, atleast until the compiler is able to accept post
IL generation plugins(like thats ever going to happen). Ideally an output
metadata file from such a tool would be used in the ide(similar to how Xml
Docs work), instead of requiring all compilers for all langauges to
implement such code.

I'm not sure everyone would agree the trade-off is worthwhile. So now
you get people wanting to turn it off! Which means you will now have

members

that lack exception information - which in turn brings us right back to
where we were :-)

LOL! Well, if I had a telescope that could see clear across the universe

all I would see is the back of my own head but it would be an interesting
journey :-)