throws keyword missing in C#

  • Thread starter Thread starter vijaynats
  • Start date Start date
V

vijaynats

Why isn't there a 'throws' keyword in C# like java -

i would like to declare a function and say -

public int addup(int a, int b) throws ArithmeticExceptio,
DivideByZeroException
{
...
...
}

just like java so that addup function only throws these two types of
exceptions

is there any alternate coding? and if its not been included then why?

i'm new to c#

Your views are eagerly awaited

Thanks

Vijay
 
 
Microsoft has decided against adding the Throws syntax which would force
the caller of the method to explicitly catch the exceptions it throws.

For clearification to the user of the methods, you could use XML
comments and add the exception(s ?) element. But this is purely
documentual and don't enforce coding.
 
There is no "throws" in C# because C# doesn't have checked exceptions
(exceptions that must have handlers at compile time).

For example, in java, any class method that *could* produce an
IOException *must* have a try-catch block for it, or say "throws" which
means let the caller worry about it. If you don't do this, your code
won't compile. This is the difference.

At compile time, C# doesn't check/care if you handle exceptions or not,
so there's no need for a throws keyword. C# only cares when an
exception is actually thrown, not if it may be thrown.

This is how it works to the best of my understanding.

Hope this helps,
-Dave
 
just like java so that addup function only throws these two types of
exceptions

is there any alternate coding? and if its not been included then why?
Click to expand...

The short answer is no, there are no checked exceptions in C#. The
designer of the language discusses this decision in this interview:

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

The nearest you can get is to use the <exception> tags in your XML
documentation, and distribute NDoc generated docs with your
code/assemblies so that other people can see which exceptions you throw
(which is exactly what MS do in the MSDN documentation). You can't rely
on the compiler to tell you about unhandled exceptions, however, like
you may be used to in java.
 
Vijay,

In addition to what was said before about whether or not there is a
throws construct similar to Java, I figured I could add a little bit to the
why.

One of the main reasons (if not the main and overriding one) is that
with checked exceptions, most people (at least from the perspective of those
creating C#) just resorted to writing "throws Exception" as a catch-all. As
code bases became larger and larger, it becomes more prohibitive as you add
different exceptions further down in your call stack.

Hope this helps.
 
Chad Z. Hower aka Kudzu said:
throw is C# is very different than throwS with an s in Java. C# AFAIK does
not have the equivalent of throws in Java. In C# and like most other
languages, throws is simply not needed.
Click to expand...

That suggests that it's some kind of limitation of Java that forced its
inclusion, whereas in fact it was designed as a *feature* of Java.
Whether or not it's a *good* feature is a matter of much debate, of
course.
 
I agree with Jon. It was a feature of Java. Whether it worked well is a
moot point.

What I wish C# would provide is enough information in each assembly
that a tool such as FxCop could tell you what exceptions your methods
will throw, and complain when you haven't documented them all. I agree
with the C# architects that "throws" is not such a good idea,
particularly given .NET's intense focus on versioning, but being left
without any way of discovering what exceptions a method / property
might throw seems to me a huge oversight.
 
Bruce Wood said:
I agree with Jon. It was a feature of Java. Whether it worked well is a
moot point.

What I wish C# would provide is enough information in each assembly
that a tool such as FxCop could tell you what exceptions your methods
will throw, and complain when you haven't documented them all.
Click to expand...

In another post I made a similar point. A combination of code analysis and a
few well thought out attributes could provide an effective alternative. You
could actually have two FxCop rules, one requiring the documentation of
exceptions, and another effectively enforcing checked exceptions for the
Java fans.

If you coupled code & exception documentation analysis with a:
ThrowsAttribute(type[, description]) - To explicitly add an exception not
visible in code (e.g. created via Reflection or something)
 
Jon Skeet said:
That suggests that it's some kind of limitation of Java that forced its
inclusion, whereas in fact it was designed as a *feature* of Java.
Whether or not it's a *good* feature is a matter of much debate, of
course.
Click to expand...

I didnt mean to imply that it was because of bad construction or lack - if
thats the way it came accross Im sorry. I simply meant that in C# - its not
needed becuase it doesnt have the same "concept".


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/
 
Back
Top