throws keyword

[Emre DÝNÇER]

does c# provide an alternative to the throws keyword in javA?so that my
client developer will strictly implement the exceptions that my methods may
throw?
thanks in advance

 

[Marc Gravell]

No. You can, however, document those that are reasonably expected via
an <exception ... /> tag in the comments.

Marc

 

[Lasse Vågsæther Karlsen]

does c# provide an alternative to the throws keyword in javA?so that my
client developer will strictly implement the exceptions that my methods may
throw?
thanks in advance

No.

They were chosen away because of the problems they pose and the
solutions developers will use to work around them and thus in many cases
are rendered useless.

It also makes inheritance difficult.

Documentation is your answer, not syntax or compiler checks.

 

[chris]

Just for discussion, would anyone like this functionality added?

I agree there are issues with Java's checked exception, as posed by
this typical code block:

try{ Thread.sleep(3000);}
catch (InterruptedException ie) { ??? Not a bloody thing I can do
about it ???}

If it's going to happen, and I can't do anything about it, then why am
I FORCED to catch it.

However, I wouldn't mind at all if I was warned about checked
exceptions.

WARNING: Potential Exception "UserIsAMoronException" not caught in
line 205.

Then I would at least be reminded of the possibility. I'm a smart
guy, but I can't memorize the entire C# API and all exceptions that
might be thrown. Warnings would be useful.

 

[Jon Skeet [C# MVP]]

Just for discussion, would anyone like this functionality added?

I used to be in favour of checked exceptions. I've since learned to
live without the seatbelt, as it were.

I think they were a useful experiment, but one which ultimately was
unsuccessful. I would like to see *something* in their stead, but I'm
not sure what yet.

Jon

 

[Lew]

try{ Thread.sleep(3000);}
catch (InterruptedException ie) { ??? Not a bloody thing I can do
about it ???}

Wrong. There are many bloody things you can do about that in Java. You just
don't know them yet.

In fact, handling InterruptedException in Java is one of its fundamental
idioms, and it helps a lot with concurrent programming if you know what to do
with it. Admittedly, it is a rather low-level construct.

This is not to argue for or against using checked exceptions in C#, only to
state as a point of fact that InterruptedException in Java is not only readily
managed, it's a common idiom to do so.

 

[Arne Vajhøj]

does c# provide an alternative to the throws keyword in javA?so that my
client developer will strictly implement the exceptions that my methods may
throw?

..NET chose to make all exceptions unchecked.

http://www.artima.com/intv/handcuffs.html gives some
insight in why.

Arne

 

[Arne Vajhøj]

Just for discussion, would anyone like this functionality added?

I agree there are issues with Java's checked exception, as posed by
this typical code block:

try{ Thread.sleep(3000);}
catch (InterruptedException ie) { ??? Not a bloody thing I can do
about it ???}

If it's going to happen, and I can't do anything about it, then why am
I FORCED to catch it.

In 25 lines demo code that exception is usually ignored, because
the programmer know that it will never happen.

In a real program it would not be unusual to expect the thread
to do something as a consequence of it being interrupted by
some code in the parent thread.

However, I wouldn't mind at all if I was warned about checked
exceptions.

WARNING: Potential Exception "UserIsAMoronException" not caught in
line 205.

Then I would at least be reminded of the possibility. I'm a smart
guy, but I can't memorize the entire C# API and all exceptions that
might be thrown. Warnings would be useful.

A lot of sites (maybe even most sites) has a no tolerance policy
about warnings.

Meaning that that even a warning would force people to catch.

Arne

 

[Arne Vajhøj]

Documentation is your answer, not syntax or compiler checks.

That is the traditional C/C++ way of thinking. C# has given up
that for most other things than exception checking.

Or to quote Anders Hejlsberg:

<quote>
Exactly. Frankly, they look really great up front, and there's nothing
wrong with the idea. I completely agree that checked exceptions are a
wonderful feature. It's just that particular implementations can be
problematic. By implementing checked exceptions the way it's done in
Java, for example, I think you just take one set of problems and trade
them for another set of problems. In the end it's not clear to me that
you actually make life any easier. You just make it different.
</quote>

<quote>
C# is basically silent on the checked exceptions issue. Once a better
solution is known—and trust me we continue to think about it—we can go
back and actually put something in place. I'm a strong believer that if
you don't have anything right to say, or anything that moves the art
forward, then you'd better just be completely silent and neutral, as
opposed to trying to lay out a framework.
</quote>

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

He does not prefer docs over language enforcing. But he want to do it
the right way and prefer nothing over the wrong way.

Arne

 

[Lasse Vågsæther Karlsen]

Just for discussion, would anyone like this functionality added?

I agree there are issues with Java's checked exception, as posed by
this typical code block:

try{ Thread.sleep(3000);}
catch (InterruptedException ie) { ??? Not a bloody thing I can do
about it ???}

If it's going to happen, and I can't do anything about it, then why am
I FORCED to catch it.

However, I wouldn't mind at all if I was warned about checked
exceptions.

WARNING: Potential Exception "UserIsAMoronException" not caught in
line 205.

Then I would at least be reminded of the possibility. I'm a smart
guy, but I can't memorize the entire C# API and all exceptions that
might be thrown. Warnings would be useful.

The main problem is with inheritance.

Say you build a base class with a "throws" directive on a method. How do
you expect descendant classes to override that method?

A base class that knows nothing of the possible descendants that could
be written, would ever severly limit the exceptions that could possibly
be thrown from descendants, or have to forego the throws keyword altogether.

I think this was the major reason for not including it.

I'm all for more compiler checks but I don't see how this could be done
in any meaningful manner.

There are many things the compiler can't check for you, logic for
instance, which means that some point it's up to the programmer to know
what he's doing and do the right thing. Documentation is the best tool
here IMO.

 

[Lasse Vågsæther Karlsen]

That is the traditional C/C++ way of thinking. C# has given up
that for most other things than exception checking.

Or to quote Anders Hejlsberg:

He does not prefer docs over language enforcing. But he want to do it
the right way and prefer nothing over the wrong way.

Arne

I should have qualified my statement more. I was talking about the
current way checked exceptions are being done and I fully agree with
what he wrote, in that you just trade one set of problems with another.
Inheritance, IMO, would be particularly painful to get to grips with.

If checked exceptions can be done so that they are meaningful and not
just *different problems*, I want them too.

 

[chris]

Wrong. There are many bloody things you can do about that in Java. You just
don't know them yet.

In the example given, which I admit was rather simplistic, there
really isn't anything you can do about it.

You are right in that there are several things I MUST do if a
MEANINGFUL thread is interrupted (save state, try and recover, exit
gracefully and try again), but not in the STATIC sleep() method other
than a) ignore b) try again (If I really must sleep).
Short of virtual machine errors, I can't think of anything that would
cause Thread.sleep() to throw an exception.
Perhaps that would have been better served by throwing an error rather
than an exception.