Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Discovering possible exceptions throw?

Does anybody know if there is a way to discover all of the exceptions that a method could possibly throw? 

In Java, the compiler discovers this for you, and requires you to explicitly list exceptions after each method signature.  That’s not the case in C#, so it raises the question, “How confident are we that this code catches all of the exceptions that it should?” 

Back when I used Java, I was annoyed that the compiler required you to list them explicitly, but now that I'm using C#, I wonder if my code is bulletproof, or if I'm just getting into a habit of allowing exceptions to "float all the way up".

plioi
Thursday, May 26, 2005

==> I wonder if my code is bulletproof

It's not.

No code is.

Sgt. Sausage
Thursday, May 26, 2005

"I wonder if my code is bulletproof, or if I'm just getting into a habit of allowing exceptions to "float all the way up".
"

Go back and read the 2000+ posts out here on exceptions that have occurred within the past two weeks. Please don't get that mess started again.

matt
Thursday, May 26, 2005

Then I'll rephrase my question:

Does anybody know if there is a way to discover all of the exceptions that a method could possibly throw?

plioi
Thursday, May 26, 2005

No

Dennis Forbes
Thursday, May 26, 2005

Or rather yes, the answer is no

Dennis Forbes
Thursday, May 26, 2005

Actually it should be possible but isn't easy. I'm surprised that no one has written a tool for this yet (ISV's... are you listening?). The Java compiler does this so we know that it is also possible for .NET (just a little harder). By reverse engineering .NET IL should be able to see the exceptions that can be thrown for any given method. The hard part is that you would have to recursively walk through every method call to determine all of the possible exceptions (methods call methods which call methods...). Sounds like a great idea for a world-class tool.

As I stated in one of the 2000+ threads a few weeks ago, Java is trying to solve the wrong problem with checked exceptions. They are trying to show what exceptions can be thrown when this should be able to be accomplished with a documentation tool instead of a language construct. Additionally, Java doesn't guarantee that an exception can't be thrown because Runtime Exceptions don't have to be declared. Finally, knowing the actual type of exceptions that can be thrown has little relevance in most cases. Just knowing that "some" exception could be thrown is typically enough. Java's checked exceptions handcuff programmers for the sake of "better documentation".

matt
Thursday, May 26, 2005

There is a reason why C# does not do "checked exceptions".  Here are direct words from the creator, Anders Hejlsberg :

http://www.artima.com/intv/handcuffs.html

RM
Friday, May 27, 2005

> Actually it should be possible but isn't easy

In many real-world cases it isn't possible.  For example, with the provider-model design pattern which is becoming more common in .NET you don't know which provider you're calling until runtime, so can't have any idea what exceptions will be thrown.  Similarly for the common pattern in distributed applications of accessing a different tier via an interface instantiated using a factory pattern.

I know most guidelines recommend catching specific exception types, and I see the value of this in a few, relatively uncommon situations where you are calling a low level method (e.g. accessing a file; parsing input; ...).  But for top-level exception handlers in the UI tier, it's almost always necessary to catch System.Exception.

Joe
Friday, May 27, 2005

*  Recent Topics

*  Fog Creek Home