Throw checked exception

[gulshan]

The idea is to let an Exception be marked as checked during throw in a method and thus requiring exception-handling (for that specific type of exception) at call-site of the method. It would look something like-

void Method1()
{
    throw new Exception();
    throw checked(new ArgumentException());
}

void CallSite()
{
    // No exception-handling - error
    Method1();

    // exception-handling for ArgumentException - ok
    try { M(); }
    catch (ArgumentException e) { throw e; }

    // indirect exception-handling for ArgumentException - ok
    try { M(); }
    catch (Exception e) { throw e; }

    // No exception-handling for ArgumentException - error
    try { M(); }
    catch (ApplicationException e) { throw e; }
}

Is there any benefit marking some exception as to be handled at call-site?

[HaloFour]

The Trouble with Checked Exceptions

[huoyaoyuan]

C# was designed intentionally NOT to use checked exceptions.

[gulshan]

Went through it and some other related articles again. Will try to share my thoughts later. But it's true that any kind of checked exception is not quite suitable in/for C#. Not yet.

[gulshan]

There are three major problems with checked exceptions, or at least how it is implemented in Java-

• Versioning: If some method/API decides to include another exception throwing path, its signature has to change. It's like an implementation details being exposed at signature level. And then, changing in that type of implementation details is a breaking change because of it.
• Scalability: When a method is calling several other methods throwing exceptions, either it has to handle the exception or declare it at the signature, for each and every one of all the exceptions declared by all methods being called. This becomes very ugly very fast.
• Non-Expression exception handling: In languages like Java or C#, exception/error handling is not an Expression. So it becomes very tiresome to handle the exceptional cases and focus on the happy path is lost.

For 1 and 2, the solution is not being specific about the Exceptions in the declaration/signature of methods. Joe Duffy suggested only throws is sufficient in the method declaration, names/types of exceptions not needed, for C#.

For 3, the language has to "expressionize" exception/error handling. Tried to explore different ways of it for C# in #2734

And we can look at some newer languages like Rust, which has "checked exceptions" of some sort but handles these issues well enough. But the last question is- is this really needed in C#? Isn't C# well enough for now? There were lengthy discussions on exception/error handling in this repo. If there was not some concerns with current state of affairs, there would be no discussion.

[theunrepentantgeek]

Joe Duffy suggested only throws is sufficient in the method declaration, names/types of exceptions not needed, for C#.

Joe was talking about Midori, a Microsoft internal systems development language that was derived from C# but which differs from it in many fundamental ways. Midori didn't need to deal with 20 years of existing code and established idioms and was free to take an entirely new approach.

Much of the perceived benefit of checked exceptions is that reading the method signature tells you which exceptions might be thrown by the code.

Watering down the proposal by omitting the list of specific exceptions weakens the proposal in precisely the area where proponents want specificity.

A bare throws keyword would be extremely viral. Changing one existing method by adding throws would trigger a cascade of minor changes across callers in the same way that introducing async into a method requires all callers now be async-aware as well. This is another form of the versioning problem.

Lastly, virtually every method in .NET can throw an exception, not just those that include a throw statement. Any code that allocates memory can trigger an OutOfMemoryException. Any code that calls another method can trigger a StackOverflowException. Any code that accesses memory can trigger an AccessViolationException. And that's before we start looking at what happens when you call library code - where, for example, code that read a file can trigger an IOException.

I believe a throws keyword would effectively become noise, not signal, because it would appear on every single method. Seeing it wouldn't tell readers anything useful.

[canton7]

I don't disagree with the sentiment one iota, but just to add: some exceptions are thrown by the runtime in a way which means that they cannot be caught, including StackoverflowException, OutOfMemoryException, ExecutionEngineException, etc. If (hypothetically) C# got checked exceptions, it would make sense to me that uncatchable exceptions thrown by the CLR would be exempt.

That said, you've still got the catchable AccessViolationException and the semi-catchable ThreadAbortException. You'd have to make a Java-esque distinction between RuntimeException / other exception types (you wouldn't want throws ArgumentNullException everywhere, surely?), and then speed-run all of the same problems that Java hit.

[HaloFour]

There is a fourth problem, that checked exceptions and functional programming do not mix well. This has become painfully apparent in Java since lambdas and streaming APIs have been added. The issue is that the exceptions are a part of the signature of the lambda (whether that be implemented via functional interface or delegate) and cannot flow through a fluent API. That forces every lambda expression to have to handle checked exceptions, which it generally can't do in any practical manner exception by rethrowing as a checked exception. Something like DUs can solve this better but I still don't believe it works well without HKTs otherwise every fluent API would require nesting mapping lambdas.

I'm not philosophically opposed to the idea of checked exceptions being added to the language, but I've yet to see an implementation of them in any language that I think would make for a good addition. The Java approach is most certainly wrong, but I also think that extends to any approach that requires adorning the method signature and putting the onus on the caller to handle or declare that it also throws.

IMO it's pretty telling that (as far as I'm aware) every other JVM language has pretty much ignored checked exceptions.

[theunrepentantgeek]

The idea is to let an Exception be marked as checked during throw in a method and thus requiring exception-handling (for that specific type of exception) at call-site of the method.

Requiring the exception to be handled at the call-site of the method would strongly encourage developers to write large methods, as you'd be preventing them from slicing off chunks of code into helper methods.

Even when I handle exceptions by catching and compensating for their occurrence, I rarely do so in the method directly calling the method that throws. Handling is usually several layers up the call stack.

[AartBluestoke]

Exception are not supposed to be something thrown so routinely that you need a function to effectively declare "i might return a value, or a thrown MyIntegerDataParsingException".

Discriminated Unions of Value||Error are probably more appropriate if you want to declare specific error type return values.

[canton7]

DU's have the same versioning and scalability issues, unless you go down the route that a Result can contain an Error, but you can't tell what types of errors it can contain, which is little different to a checked throws Exception

[AartBluestoke]

agreed. the list of exception you can throw can grow making code brittle to version changes. But you can atleast have the 'checked' exceptions returned, and the exceptional Exceptions thrown;

(int Value |(Exception ParseError| SqlException DatabaseError) Error) f(){...}
allows you to somewhat have the best of both worlds - you can force your reciever to handle the exception you return, and the general category of the error you wish to throw.,

[Richiban]

I agree with some of the sentiment here that checked exceptions (i.e. ones where each Exception type is listed in the signature) are better implemented as a special type of return value (bring on discriminated unions!).

I do like the idea of being able to distinguish between methods that throw and those that don't, but unfortunately I think that's pretty much impossible to retrofit onto any language, let alone one that's 20 years old! I'm also sympathetic to @theunrepentantgeek 's argument that it may end up being that the vast majority of methods would need to be annotated, vastly reducing its value.

[gulshan]

I no longer support this idea of throwing checked exception. Closing the discussion.