Specifying the Exceptions Thrown by a Method

[attilaersek]

In Java language we have the throws keyword that helps us in notifying the programmers that calling a method could result in specific exceptions. Wouldn't that make sense for C# as well?
For example in case:

public void Method(string argument) throws ArgumentOutOfrangeException
{
    if(String.IsNullOrEmpty(argument)) throw ArgumentOutOfrangeException(nameof(argument));
}

Calling the above method without explicitly handling the exception, or marking the caller method with the same throws syntax could result in compiler warning or error based on settings.

In my opinion it has many benefits especially for library developers.

[Joe4evr]

Never gonna happen.

[MkazemAkhgary]

In c# you can use xml documentation.

/// <summary>
/// this is foo
/// </summary>
/// <exception cref="NullReferenceException">
/// foo can throw NRE
/// </exception>
public void Foo()
{
}

[HaloFour]

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

I tend to agree. I've seen a good deal of Java code that contorts itself just to satisfy the compiler when it comes to checked exceptions. Lots of catch and swallow, lots of catch and rethrow unchecked, etc. And still the code is often enough not defensive to unchecked exceptions such as NullPointerException.

I'd rather see something more comprehensive, like method contracts, that can surface the metadata necessary to avoid exceptions in the first place.

[Eirenarch]

No!

[attilaersek]

well thanks for the input, and that's why i first imagined that as a compiler feature that can be optionally tuned from silent to warnings and errors. the xml documentation itself is good for understanding but not for verifying the code contracts. so just as @HaloFour mentioned method contracts could be a satisfying solution, just as like extending code metadata or using code analyzers.

[svick]

In my opinion, the problem with checked exceptions is classifying exceptions into those that should be checked and those that shouldn't. Using Eric Lippert's terminology:

• Boneheaded exceptions, like ArgumentOutOfRangeException, should not be checked. They indicate bugs and should not be caught; pestering programmers about catching them is counterproductive.
• Exogenous exceptions, like FileNotFoundException, should be checked. They indicate problematic situations in code and forgetting to catch them is likely a bug. Pestering programmers that they should catch them is the right thing to do for robust programs.

If checked exceptions are added to C#, they should be very careful that this distinction is maintained (which also requires that exceptions that have the same type belong to the same category).

[Eirenarch]

@svick while some exceptions are clearly in the boneheaded camp there are barely any exceptions that should always be caught. For example what if your code just created the file? The lack of a file indicates a bug so the program should crash but the programmer was forced to catch the exception. At best he rethrows it as a runtime exception at worst he writes empty catch and corrupts the program state. For every example of "this should always be handled" there is a counterexample of "I am sure this can never happen and if it happens it is a bug"

[svick]

@Eirenarch

For example what if your code just created the file? The lack of a file indicates a bug so the program should crash but the programmer was forced to catch the exception.

If another process deleted the file, then it's not a bug. You might be okay with your program crashing in that situation, but I'm not sure I would call such program "robust".

Though not all programs should be 100 % "robust" by this definition. Maybe an easy way of rethrowing a checked exception as unchecked could help?

[mattwar]

There was a decision pre C# 1.0 never to do this. But who knows. 👀

[HaloFour]

@mattwar

At this point I seriously doubt the feature could be implemented, at least not the same way that they work in Java. As Anders mentioned, throws is a part of the method contract and amending that list is a breaking change. None of the BCL advertises checked exceptions, so integrating it into the BCL would be practically breaking everything. There's also the big problem that unlike Java the BCL never separated the hierarchy of exceptions into "checked" and "unchecked".

Conceptually checked exceptions can definitely be quite useful, but I think the strictness of it in Java is what creates a lot of the problems. If the compiler/runtime didn't enforce the checked exceptions as a part of the contract and their enforcement was limited by default to warnings that would give the developer more flexibility in how they manage those exceptions. But that sounds more like an analyzer than a compiler feature.

[attilaersek]

@mattwar I was not aware of that early decision and reading through the discussion definitely makes sense. Since we have roslyn analyzers as well, it can be used for similar purpose.
My first post with the example was not precise enough, I never wanted to ask that every exception should be checked, only those that are explicitly specified by the api designer.

EDITED: sry. comment box is not phone screen size friendly.

[Eirenarch]

To be honest I always wondered why the IDE can't just follow all possible calls in a method and show all possible exceptions.

[jnm2]

@Eirenarch BCL calls? Interface calls? Reflection? Seems like you'd quickly list thousands.

[Eirenarch]

@jnm2 well it would dive into the BCL of course. Reflection will be ignored (what happens with checked exceptions with Java reflection?). Interface calls is a problem though

[yaakov-h]

interface calls, abstract calls, and other virtual calls... which is probably most calls. 😄

[jnm2]

Yep. To say nothing of the reference assemblies problem, where all the method bodies are => throw null;.

[alrz]

@Eirenarch

To be honest I always wondered why the IDE can't just follow all possible calls in a method and show all possible exceptions.

See dotnet/roslyn#15573