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

[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.

"WoodBeeProgram mer" <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******** ******@TK2MSFTN GP09.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
(ExecutionEngin eException, 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@@m sn.com> wrote in message
news:%2******** ********@TK2MSF TNGP12.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
ApplicationExce ption. Knowing that ApplicationExce ptions 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 ApplicationExce ption anyway. This also doesn't account for the

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

exceptions inherited ApplicationExce ption 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.co m> wrote in message
news:O7******** ******@TK2MSFTN GP09.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******** ******@TK2MSFTN GP11.phx.gbl...

"Rob Teixeira [MVP]" <RobTeixeira@@m sn.com> wrote in message
news:ux******** ********@tk2msf tngp13.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 :-)