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

[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]]

On Nov 23, 3:52 pm, chris <[e-mail]:

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]

chris wrote:

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.

--
Lew

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Emre DÝNÇER wrote:

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

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

chris wrote:

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

[chris]

On Nov 23, 12:19 pm, Lew <[e-mail]:

chris wrote:

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