Adding Checked Exceptions to C#

  • Thread starter Thread starter Jeff Louie
  • Start date Start date
Jeff,

Exception handling seems to crop up at least once a month. This is probably
going to be another one of those long threads.

I agree with checking conditions before trying to perform an action (where
realistically feasible) but I have little need for anymore than one
Exception class. All I ever do with an exception is display a message to the
user (depending on the type of application) and log it. If I need to take
different cause within code then I check for the condition before hand, in
which case I cannot normally do this in a generic class which wraps up
common functionality.

if (!File.Exists(file))
{
throw new FileNotFoundException(filePath);
}
Click to expand...

Your example code checks if the file exists but simply throws an exception,
how does this differ to what the framework does? Yes it performs a close
before an open but I prefer to do this explicitly within the main calling
code. For me trying to open a closed file should throw an exception not hide
the bug in my code where I failed to do so
came up with a suggestion about how to add checked exceptions to C#
Click to expand...

In any case your proposal does not really fall into the category of
"checked" exceptions. I seem to remember seeing something in
www.CodeProject.com where somebody achieved this by using Attributes.

But perhaps I have missed your point...

Phil...
 
If I get it right your proposal is to define at least 4 different exceptions
for each class?

And what about interfaces?

class MyThread : IRunnable
{
public void Run(){}
}

What exceptions will run throw? I assume both IRunnableException AND
MyThreadException.
 
Jeff Louie said:
I drank too much coffee last night and came up with a suggestion about
how
to add checked exceptions to C#

http://www.geocities.com/jeff_louie/OOP/oop14.htm

Comments expected <g>
Click to expand...

As best I can tell, this catch by contract suffers from the same problem I
have with regular checked exceptions.

Why is it that I would have to catch MyClassFileNotFoundException and
YourClassFileNotFoundException simply because of artificial exception
contracts? Or worse MyClassYourClassFileNotFoundException and
YourClassMyClassFileNotFoundException.

It seems to me you may actually end up with several dozen exceptions that
mean the same thing, but just have different points of origin.
 
Daniel O'Connell said:
As best I can tell, this catch by contract suffers from the same problem I
have with regular checked exceptions.

Why is it that I would have to catch MyClassFileNotFoundException and
YourClassFileNotFoundException simply because of artificial exception
contracts? Or worse MyClassYourClassFileNotFoundException and
YourClassMyClassFileNotFoundException.

It seems to me you may actually end up with several dozen exceptions that
mean the same thing, but just have different points of origin.
Click to expand...

Now, for the plus sides.

I do think that pre|post-conditions and exceptions could be tied together.
I've argued the point before, and I personally would like a more passive
checked exception solution. Somethign that defines input, state, and perhaps
output constraints as well as a response(exception) for invalid values, but
that does not enforce any actions. Basically a DbC implementation that is
cleanly tied to C# combined with checked exceptions, but built more for
better tools than for definate correctness(I don't really believe such a
thing is possible, thus its silly to try to pretend it is).
 
Daniel O'Connell said:
Now, for the plus sides.

I do think that pre|post-conditions and exceptions could be tied together.
I've argued the point before, and I personally would like a more passive
checked exception solution. Somethign that defines input, state, and
perhaps output constraints as well as a response(exception) for invalid
values, but '
Click to expand...

Err, tht should be, "input, output, and perhaps state"
 
Hi Cody... Well there are three proposals. If all three are implemented
than any class that throws a checked exception would need to define at
least three class level exceptions such as:
MyClassException
PreConditionException
FileNotFoundException

A more simple approach would be just to do
MyClassException
FileNotFoundException

The framework would define System.CheckedException

I had not thought about interfaces, but if an interface declared that a
checked exception could be thrown using the throws keyword I suspect
that the implementing class would define the exception hierarchy as
above. Existing exceptions would not be affected since they do not
inherit from System.CheckedException and are not declared in a method
using a throws keyword.

If a user did not want to throw checked exceptions, the user would not
need to declare any class level checked exceptions, but would need to
catch and handle any checked exceptions thrown by suppliers to the
class.

Regards,
Jeff
If I get it right your proposal is to define at least 4 different
Click to expand...
exceptions for each class?

And what about interfaces?<
 
Phil...I rewrote the chapter a bit, so hopefully my points are clearer.

1) David Abrahams has argued that one person's exception is another
person's error, making the distinction less than useful.... In this
chapter I suggest implementing a systematic approach to exceptions
discussed by Herb Sutter that removes such ambiguity.

2) My second suggestion is to add checked exceptions to C# by requiring
the compiler to enforce what I am calling catch by contract. Any class
that throws a checked exception must declare a class level base
exception type and all CHECKED exceptions thrown by the class must
inherit from this class level base exception.

Versioning and scalability concerns are addressed by insuring that a
class level base exception exist and that all checked exceptions inherit
from this class level exception. Exceptional method calls can conclude
with catch(SomeBaseClassException e) {}. Catch by contract should
suppress the urge to catch{}!

3) Finally, I suggest that Herb Sutter's concept of an error can be
captured in the exception hierarchy.

Regards,
Jeff
 
Hi Daniel.. or is Dan OK?
With regular checked exceptions you can just explicitly declare that the
client method throws the exception, freeing you from having to catch it.
It will just bubble up. Or you can do a catch{} <g>, which unfortunately
happens more than we admit. With catch by contract, bubbling up a
checked exception would require more work: catch, convert and rethrow.
So I agree, catch by contract is meant for exceptions that are going to
be handled by the client, Else use regular, hence unchecked, exceptions.

Regards,
Jeff
As best I can tell, this catch by contract suffers from the same
Click to expand...
problem I have with regular checked exceptions.

Why is it that I would have to catch MyClassFileNotFoundException and
YourClassFileNotFoundException simply because of artificial exception
contracts?<
 
Jeff Louie said:
Hi Daniel.. or is Dan OK?
Click to expand...

Dan is fine, ;)
With regular checked exceptions you can just explicitly declare that the
client method throws the exception, freeing you from having to catch it.
It will just bubble up. Or you can do a catch{} <g>, which unfortunately
happens more than we admit. With catch by contract, bubbling up a
checked exception would require more work: catch, convert and rethrow.
So I agree, catch by contract is meant for exceptions that are going to
be handled by the client, Else use regular, hence unchecked, exceptions.
Click to expand...

My concern is more in, say, class A contains class B. When one of class B's
methods fails, class A would have to wrap those into exceptions that are
valid with A(In other words ABException, lol). Thus, you could end up
writing alot of:

try
{
... //do something
}
catch (CheckedException ce)
{
throw new MyCheckedException(ce);
}

just to maintain the exception hiearchy. Both exceptions are technically
something the utlimate client must handle, but who's to say who the ultimate
client is? While in some cases the client may be one step away, would you
want to constrict your code so that it is only valid within the context of
immediate use? I don't think I would.
So, how do you decide when to use unchecked?
 
Back
Top