Adding Checked Exceptions to C#

[Jeff Louie]

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>

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Phil Jenson]

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(f ile))
{
throw new FileNotFoundExc eption(filePath );
}
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#
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...

"Jeff Louie" <je********@yah oo.com> wrote in message
news:eI******** ******@TK2MSFTN GP11.phx.gbl...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>

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[cody]

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 IRunnableExcept ion AND
MyThreadExcepti on.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
"Jeff Louie" <je********@yah oo.com> schrieb im Newsbeitrag
news:eI******** ******@TK2MSFTN GP11.phx.gbl...

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>

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Daniel O'Connell [C# MVP]]

"Jeff Louie" <je********@yah oo.com> wrote in message
news:eI******** ******@TK2MSFTN GP11.phx.gbl...

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>

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 MyClassFileNotF oundException and
YourClassFileNo tFoundException simply because of artificial exception
contracts? Or worse MyClassYourClas sFileNotFoundEx ception and
YourClassMyClas sFileNotFoundEx ception.

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 [C# MVP]]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eG******** ******@TK2MSFTN GP09.phx.gbl...

"Jeff Louie" <je********@yah oo.com> wrote in message
news:eI******** ******@TK2MSFTN GP11.phx.gbl...

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>

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 MyClassFileNotF oundException and
YourClassFileNo tFoundException simply because of artificial exception
contracts? Or worse MyClassYourClas sFileNotFoundEx ception and
YourClassMyClas sFileNotFoundEx ception.

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.

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(except ion) 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 [C# MVP]]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:e5******** ******@tk2msftn gp13.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:eG******** ******@TK2MSFTN GP09.phx.gbl...

"Jeff Louie" <je********@yah oo.com> wrote in message
news:eI******** ******@TK2MSFTN GP11.phx.gbl...

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>

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 MyClassFileNotF oundException and
YourClassFileNo tFoundException simply because of artificial exception
contracts? Or worse MyClassYourClas sFileNotFoundEx ception and
YourClassMyClas sFileNotFoundEx ception.

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.

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(except ion) for invalid
values, but '

Err, tht should be, "input, output, and perhaps state"

[Jeff Louie]

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:
MyClassExceptio n
PreConditionExc eption
FileNotFoundExc eption

A more simple approach would be just to do
MyClassExceptio n
FileNotFoundExc eption

The framework would define System.CheckedE xception

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.CheckedE xception 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

exceptions for each class?

And what about interfaces?<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jeff Louie]

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(SomeBaseC lassException 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

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jeff Louie]

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

problem I have with regular checked exceptions.

Why is it that I would have to catch MyClassFileNotF oundException and
YourClassFileNo tFoundException simply because of artificial exception
contracts?<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Daniel O'Connell [C# MVP]]

"Jeff Louie" <je********@yah oo.com> wrote in message
news:eK******** ******@TK2MSFTN GP11.phx.gbl...

Hi Daniel.. or is Dan OK?
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.
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 (CheckedExcepti on ce)
{
throw new MyCheckedExcept ion(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?
Regards,
Jeff

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 MyClassFileNotF oundException and
YourClassFileNo tFoundException simply because of artificial exception
contracts?<

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!