How to use Java-style throws keyword in C#?

Question

In Java, the throws keyword allows for a method to declare that it will not handle an exception on its own, but rather throw it to the calling method.

Is there a sim

Answer 1

After going through most of the answers here, I'd like to add a couple of thoughts.

1. Relying on XML Documentation Comments and expecting others to rely on is a poor choice. Most C# code I've come across does not document methods completely and consistently with XML Documentation Comments. And then there's the bigger issue that without checked exceptions in C#, how could you document all exceptions your method throws for the purpose of your API user to know how to handle them all individually? Remember, you only know about the ones you throw yourself with the throw keyword in your implementation. APIs you're using inside your method implementation might also throw exceptions that you don't know about because they might not be documented and you're not handling them in your implementation, so they'll blow up in face of the caller of your method. In other words, these XML documentation comments are no replacement for checked exceptions.

2. Andreas linked an interview with Anders Hejlsberg in the answers here on why the C# design team decided against checked exceptions. The ultimate response to the original question is hidden in that interview:

The programmers protect their code by writing try finally's everywhere, so they'll back out correctly if an exception occurs, but they're not actually interested in handling the exceptions.

In other words, nobody should be interested in what kind of exception can be expected for a particular API as you're always going to catch all of them everywhere. And if you want to really care about particular exceptions, how to handle them is up to you and not someone defining a method signature with something like the Java throws keyword, forcing particular exception handling on an API user.

--

Personally, I'm torn here. I agree with Anders that having checked exceptions doesn't solve the problem without adding new, different problems. Just like with the XML documentation comments, I rarely see C# code with everything wrapped in try finally blocks. It feels to me though this is indeed your only option and something that seems like a good practice.

Answer 2

Here is an answer to a similar question I just found on bytes.com:

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

Answer 3

In Java, you must either handle an exception or mark the method as one that may throw it using the throws keyword.

C# does not have this keyword or an equivalent one, as in C#, if you don't handle an exception, it will bubble up, until caught or if not caught it will terminate the program.

If you want to handle it then re-throw you can do the following:

try
{
  // code that throws an exception
}
catch(ArgumentNullException ex)
{
  // code that handles the exception
  throw;
}

Answer 4

There are some fleeting similarities between the .Net CodeContract EnsuresOnThrow<> and the java throws descriptor, in that both can signal to the caller as the type of exception which could be raised from a function or method, although there are also major differences between the 2:

• EnsuresOnThrow<> goes beyond just stating which exceptions can be thrown, but also stipulates the conditions under which they are guaranteed to be thrown - this can be quite onerous code in the called method if the exception condition isn't trivial to identify. Java throws provides an indication of which exceptions could be thrown (i.e. IMO the focus in .Net is inside the method which contracts to prove the throw, whereas in Java the focus shifts to the caller to acknowledge the possibility of the exception).
• .Net CC doesn't make the distinction between Checked vs Unchecked exceptions that Java has, although the CC manual section 2.2.2 does mention to

"use exceptional postconditions only for those exceptions that a caller should expect as part of the API"

• In .Net the caller can determine whether or not to do anything with the exception (e.g. by disabling contracts). In Java, the caller must do something, even if it adds a throws for the same exception on its interface.

Code Contracts manual here