Identifying what exceptions a class can through

  • Thread starter Thread starter Simon Harvey
  • Start date Start date
S

Simon Harvey

Hi,

Does anyone know an easy way to identify the exceptions that a class can
potentially throw.

I was looking for a list of the exceptions that the Hashtable class can
potentially provide, however the documentation on the Hashtable doesnt
provide a list. I find that a bit silly given that its pretty important and
it would be useful to have that information in the same place as all other
pertinent information in the documentation.

Does anyone know how I can identify this info?

Thanks everyone

Kindest Regards

Simon
 
Hi Simon,

In C# there is no way to explicily know the exceptions a class can throw,
for the framework classes you can rely in the help of each of the members,
but it may have errors so I advice you that you always have an Exception
clause at the end.

IIRC Eiffel had a feature that each method had to especify the exception
it could throw and the compiler check for it at compiler time, nothing like
this exist for c# though.

Cheers,
 
IIRC Eiffel had a feature that each method had to especify the
exception
it could throw and the compiler check for it at compiler time, nothing like
this exist for c# though.
Click to expand...

This is not Eiffel, this is Java. In Java, every method has an optional
"throws" clause that lists the exception that the method may throw. The
compiler checks that all the exceptions listed in the throws clause are
properly caught somewhere along the call chain (except if the Exception
class derives from RuntimeException, in which case it does not need to be
listed in the throws clause).

Eiffel does not even have exception classes. It lets you catch exception but
it does not let you easily discriminate among exception types (at least the
original version of Eiffel that I used a long time ago). Also, Eiffel's
catch equivalent rethrows by default and you have to use a special "retry"
mechanism to prevent the exception from being propagated to the caller.

There has been considerable debate on whether the "throws" clause is a good
or bad thing (search for checked vs. unchecked exception in Google Groups).
It is probably not worth starting another thread on this polemic issue.

Bruno.
 
In C# there is no way to explicily know the exceptions a class can throw,
for the framework classes you can rely in the help of each of the members,
but it may have errors so I advice you that you always have an Exception
clause at the end.
Click to expand...

I dint undestand how you can advice to have a catch all exception i g ues
you mean:

....
catch(Exception ex)
{
//We are sure to catch all exception
}

I think this is very poor design except when you are working in the "outer
bound" of your program. Many systemException like StackOverFlow could happen
when you aint expecting them. These would be caught in the catch(exception
ex) clause. Your application will then still run even though the best
solution was to shut down the entire program.

This is esspecially true when designing utilityclases. They should ONLY
cacth exception they know how to handle, else... let them go and let the
user of the classlib decide what's right to do.

What is your opinion?

Anders Jacobsen, DK
 
He was probably referring to a Java feature: the "throws" clause. Java
forces you to list the exceptions that a method may throw in the method's
signature:

public void MyMethod() throws MyException { ... }

C# borrowed a lot from Java but it did not retain this "feature". And people
have contrasted opinions on whether this is a good or bad thing (just search
for checked vs. unchecked exceptions in Google groups).

Bruno.
 
He was probably referring to a Java feature: the "throws" clause. Java
forces you to list the exceptions that a method may throw in the method's
signature:

public void MyMethod() throws MyException { ... }

C# borrowed a lot from Java but it did not retain this "feature". And people
have contrasted opinions on whether this is a good or bad thing (just search
for checked vs. unchecked exceptions in Google groups).
Click to expand...

<snip>
C# didn't retain this "feature" because real programers don't
require such training wheels.

Oz
 
C# didn't retain this "feature" because real programers don't
require such training wheels.
Click to expand...

I did not want to start another debate on this, which is why I redirected to
Google groups and took a neutral stand.
But I am on the "real programmers" side ;-)

Bruno.
 
Back
Top