Checked Exceptions

[fnandes]

What about Checked Exceptions in C# like Java?

I think it would be helpful to expect all behaviors of the method/object.

public class FileUtils
{
    public void Write(string content)
        throws : DirectoryNotFoundException
    {
        ...
    }

    public void WriteGeneric<T>(string content)
        throws : DirectoryNotFoundException
        where T: class
    {
        ...
    }
}

It will enforce that every method who calls FileUtils.Write should do it within a try..catch.. statement.

[jveselka]

I believe checked exceptions are generally bad.

I recommend reading this interesting discussion with Anders Hejlsberg explaining why C# does not have them. http://www.artima.com/intv/handcuffs.html

[gafter]

It is unlikely we'd reverse ourselves on such a longstanding and deep design issue.

[Flash3001]

You should also read http://joeduffyblog.com/2016/02/07/the-error-model/

It will give a wide view about error communication in general: checked exceptions, unchecked exceptions, error codes, fail fast and how it is done in other languages.

It also present a different solution with contracts, which have a proposal in here #105

Worth reading! A lot of knowledge in one place.

[juwens]

I have to support the ticket author.

When I read articles and comments arguing against checked exceptions, they remind me much of the arguments of dynamic typing vs static typing.

When I call a method in C# it’s obvious what it’s return type will be. But I have no idea if it may raise an exception. So to be 100% sure I would need to put a try catch statement araound a lot of calls.

Checked exception and static typing have a lot similarities.

Pro

• provides more information to the compiler and developer
• help to reason about the behaviour
  Con
• make api evolution more difficult

A good practise is to write code, which is easy to reason about it’s behaviour.
And I see a big benefit if we introduce (maybe optional) checked exceptions, which outweighs the disadvantages (IMO).

I respect mr Heilsbergs opinion a lot, but C# was designed a long time ago and apparently a design goal was to make it easier for people switching to C#.

That shouldn’t hinder us today to think about possibilities to make our code more expressive and therefore our work easier. And maybe also have a different opinion than a very smart person.

PS: I remember the days when (also smart) people where arguing against static typing and emphasising the benefits of dynamic typing.

[jotabe-net]

If there are things that you need to handle, that's because they are not so exceptional, and it's much better to expose them directly in your API, so that the APi user handles them. Imagine, for example that you're implementing a program that connects to SQL Server. You could have these two cases:

1. in general, you expect your network and DB to be stable, so you don't need to worry about connection timeouts
2. in an specific case, where you know you have unstable connectivity, because of your environment, you could try to handle the timeouts, and even do retries in a very explicit way, exposing a long connectivity problem explicitly in your API response.
   In Java, with checked exceptions, you are forced to handle all the SQL exceptions. So you need to handle them, in the first case, where they make no sense, because a connection failure is something really exceptional. In the second case, it stops being exceptional, and most probably you already know it, and handle it in an explicit way.

Besides, think of many other possible exceptions that can happen: permissions, out of memory, out of disk space... are you really going to handle all the things that most probably will never happen?

And, considering the evolution of APIs, or even the exchange of implementations of an interface, what if you create something that uses a SQL Server as a backend, and thus expose the SqlServerExtension, and tomorrow you want to use Oracle or a NO SQL database?

They are very bad ideas!!

[HaloFour]

@juwens

Checked exceptions as they are implemented in a language like Java don't make API evolution difficult, they make it impossible. The exceptions are a part of the contract and it's impossible to add any others without breaking all existing consumers. So that forces implementers to group exceptions in weird ways, or just default to throwing everything as unchecked, which is insanely common. Forcing every consumer of every method to either catch/handle all of the possible exceptions or explicitly propagate them up doesn't scale. And the entire concept of checked exceptions breaks down very painfully when you start to program in a more functional manner. I think it's telling that nearly every other language on the JVM just ignores checked exceptions outright.

If C# were to ever get something like checked exceptions I could only ever see them handled like NRTs. External metadata that can be used to drive analyzers which might warn, but never anything stricter.

A much better solution would be DUs and Result<T>-like types. If an error mode is a part of the contract, encode it into the return type.

[dQw4w9WgXcQ]

Besides passing failed state along with the error, the issues you brought up have equivalents with Result. I believe this use case is rare and should honestly probably be discouraged.

Scala 3 adds checked exceptions back to the language. https://docs.scala-lang.org/scala3/reference/experimental/canthrow.html

[HaloFour]

Besides passing failed state along with the error, the issues you brought up have equivalents with Result. I believe this use case is rare and should honestly probably be discouraged.

It's an absolute necessity to work with any kind of functional programming.

Scala 3 adds checked exceptions back to the language.

As an experimental extension, and at a glance it appears to be attempting to work around the massive ergonomic problems that the JVM's own model creates. Scala is a very academic and often esoteric language, so it's hard to say what will come of the extension. But I would be interested to see if they can find a way to address the various problems of checked exceptions in a way that would make it more palatable.

[dQw4w9WgXcQ]

It's an absolute necessity to work with any kind of functional programming.

I can see that. I have to say that I don't use functional programming much outside of simple map/reduce/etc.. However, I still find the union type issue more concerning.

at a glance it appears to be attempting to work around the massive ergonomic problems that the JVM's own model creates

They actually say "Exceptions are an ideal mechanism for error handling in many situations." and raise some issues with error monads. The canthrow reference appears to provide a good overview of the considerations.

I don't believe checked exceptions are fundamentally flawed, Java's implementation was just suboptimal. IMO 2 major issues with checked exceptions in Java are

1. Too many std lib functions throw checked when they could've thrown unchecked.
2. No easy way to suppress checked exceptions to unchecked (you have to wrap in a RuntimeException).

[HaloFour]

They actually say "Exceptions are an ideal mechanism for error handling in many situations." and raise some issues with error monads. The canthrow reference appears to provide a good overview of the considerations.

It's how the language allows you to interact with them that matters. If composing over exceptions was similar to working with Result<...> or Option<T> monads, then sure.

The other question is whether such an experimental Scala 3.x feature will matter. Without support for it from the JVM and from the Scala base libraries, it kinda doesn't matter. The Scala ecosystem goes out of its way to avoid exceptions, relying on monads instead.

I don't believe checked exceptions are fundamentally flawed, Java's implementation was just suboptimal. IMO 2 major issues with checked exceptions in Java are

The problem is how do you address those issues without fundamentally breaking the contract of checked exceptions.

I also think that checked exceptions are largely pointless given that the immediate caller of any given method expected to throw really shouldn't do anything with that exception. But, more often than not, you end up forced to, in one awkward and incorrect way or another. And if the closest thing to a "correct" behavior is to rethrow as unchecked, you're defeating the entire point.

[dQw4w9WgXcQ]

How would you handle the lack of union types?

[AminEsmaeily]

Most of the references about the Checked Exception in C# are really old, without considering the new methodologies and design patterns, and around 99% of them say that this functionality/feature/design is bad. On one hand, we want to have a clean and reliable code, and On another hand, we say the maintenance of the code will be hard using Checked Exception. I believe the Checked Exception is good, especially when we are working on a class library as an external module for other systems. Each application that wants to use the class library, should know about the possible exceptions that may arise from the methods in our class library and handle them in the right way without needing trial and error. It is most useful when we want to write a unit test for our method, and there we can handle all possible exceptions with less concern about the runtime exceptions.
One of the biggest disadvantages mentioned in most of the articles about Checked Exception is the versionability. Let's check two scenarios:

1. We have created a method with some checked exceptions and for the next version, we remove them. What will happen to the modules that have used these methods?
2. We delivered our method and they have gotten used by some applications and modules, now we want to add some new exceptions to be checked. How the users should deal with the new version?

For the first case, it is really easy and the users don't need to do anything, but they can remove the unwanted handled exceptions if they want.
For the second case, receiving compile-time errors is much better than facing unhandled exceptions at runtime. It means when we use the checked exception and we want to add some Checked Exceptions to our method for the next versions, all of them will be checked in the compile-time of the clients if they update the references to the new version, and by handling the new exception, they will make sure the code will work without unexpected breaking changes. But if we don't mention it in the code and don't force the clients to handle some specific exceptions, they will update the library reference and will face the same exception at runtime and in the production environment. Then it's better to warn the clients about the exceptions at compile-time.

Another issue mentioned in the articles against Checked Exception is that developers will use a general exception handler to wrap all checked exceptions in one place, and it will make them useless. If we want to worry about whether the developer will follow the structure, then why do we have this amount of design patterns? The developer who doesn't care about the structure, won't follow the design patterns too. Then it's totally up to the developer how to deal with this feature. He/She can handle it in the right way to get a better result or can omit the exceptions by wrapping all of them in one general try-catch.

As the final word, to handle the versionability issue and decrease its defects on the client's codes, we can use different severities for each checked exception. E.g. we can use severities like Information, Warning, Error, and Fatal, and the client will have a better vision about how to deal with each exception.

You can read my article about the Checked Exception here:
Say Hello to Checked Exception from C#

and the repository to the Checked Exception extension on C# using Roslyn
Portia.Roslyn.CheckedException

[CyrusNajmabadi]

But what I did in C# is adding another feature to change the severity of the exception for the second client, or downgrade the severity to Warning, Information, or Non to get rid of the exception repack problem

This is not the part of the problem space that I think needs solving. The parts that matter to me are that this is non compisable through apis. For example, none of System.Linq is annotated. So it would not be possible to compose any exception info from any apis I annotate through these apis.

Effectively any composition API must throw everything, or swallow everything. And that's non viable for me.

[HaloFour]

@AminEsmaeily

It is your solution too, but on a larger scale (To bobble up the exception and catch it in the framework/middleware).

The exception mapper is my own code. Any HTTP framework I've worked with offers a centralized way to intercept and interpret exceptions into HTTP methods. There's rarely a reason to need/want to do that in every single controller method.

the developer just needs to add the same Checked Exception annotation to the method signature with None severity.

That is still declaring it. Sure, you provide the facility to ignore it, but then you just broke the point of checked exceptions. Given the vast majority of exceptions can't (and shouldn't) be handled by the immediate caller it just means a lot of pointlessly annotated methods.

But if you read the comments from the beginning you will find that I try to talk about the pros of the Checked Exception (If it gets used in the right way) unlike most of the articles are just attacking it.

The pros of checked exceptions are very well documented, especially in the official Java documentation. That's why the many articles on the subject don't waste time on them. The articles are from the perspective of developer ergonomics trying to use those features in real world projects. And my experience with Java is that those articles are painfully correct. And this has been known for a very long time, even before .NET was designed. It's why literally every other JVM language ignores checked exceptions. The benefits they provide are tiny and misguided. If you find them useful, and you think that your tool is helping your codebase, that's wonderful and I tip my hat to you. But your design is much too similar to Java's, and that design is simply something that would never be considered for adoption in C#.

@CyrusNajmabadi

The parts that matter to me are that this is non compisable through apis. For example, none of System.Linq is annotated. So it would not be possible to compose any exception info from any apis I annotate through these apis.

More importantly, how would you design checked exceptions so that composing over collection (or other) monads would flow those exceptions in a manner that makes sense. This is a glaring problem in Java with streams. Annotation at the method level does not remotely work here. Alternate streaming frameworks and all of the Reactive frameworks just call bankruptcy on checked exceptions entirely and go 100% unchecked. Even Java proper goes unchecked with CompletableFuture<T>, opting to throw CompletionException, which is unchecked.

[AminEsmaeily]

Thank you for your useful comments.

I've worked with offers a centralized way to intercept and interpret exceptions into HTTP methods. There's rarely a reason to need/want to do that in every single controller method.

Centralizing the exception handling in a system is very good, but based on my experience, it's better to keep it catching not handled exceptions. When we dive into exception handling, the first important thing is to handle the exception at the early stages to decrease some other problems we have already discussed. Also, sometimes we can use general exception types to be handled in a centralized place, but most of the time, we need to act exactly based on the data and information, especially when you want to be completely loosely coupled from outside of the method.

More importantly, how would you design checked exceptions so that composing over collection (or other) monads would flow those exceptions in a manner that makes sense.

Having a brief view of the System.Linq's methods shows that most of them are annotating the probable exceptions in their metadata:

But according to the generic behavior of the methods like Linq, it totally goes back to the business that is using them how to add/remove/overwrite Checked Exceptions for each method. E.g. we can use System.Linq for some in-memory data and there we have exceptions according to the memory, but in another case, we can use the same methods for the information that should come from database, and the exceptions here are related to database and IO. The biggest challenge to deal with checked exceptions in C# is here, how to deal with the generic method, and I think the C# masters can have a better solution than me for this issue.

[CyrusNajmabadi]

and I think the C# masters can have a better solution than me for this issue.

We have no solution here. Which is the primary reason there has been no movement on this issue. The ability to ape what Java has done doesn't move the needle here as it puts forth a design we know is problematic and doesn't sufficiently address the areas we've identified as being necessary to have a good solution for.

[HaloFour]

@AminEsmaeily

Having a brief view of the System.Linq's methods shows that most of them are annotating the probable exceptions in their metadata

Only for the most basic argument validation exception.

What's much more likely to happen is that the lambda passed to those methods might throw an exception, one that the method metadata itself can never know about. What's worse for LINQ methods (and iterators in general) is that their execution is deferred, so the method itself would not be throwing the exception. The IEnumerable<T> returned from the iterator might throw the exception, but that's not metadata that you can convey across method boundaries. So even if the exception were to come from the DB or some business layer directly it's still not being thrown out of the method that is being called. That inability for the checked exceptions to compose across fluent APIs and flow down to the actual consumer of the result impedes their usefulness in a large number of modern scenarios both in C# and other languages like Java.

[redradist]

@pedrobfernandes

What about Checked Exceptions in C# like Java?

I think it would be helpful to expect all behaviors of the method/object.

public class FileUtils
{
    public void Write(string content)
        throws : DirectoryNotFoundException
    {
        ...
    }

    public void WriteGeneric<T>(string content)
        throws : DirectoryNotFoundException
        where T: class
    {
        ...
    }
}

It will enforce that every method who calls FileUtils.Write should do it within a try..catch.. statement.

I like this idea !!

I discussed it long time ago, but all team members said me the same as they said to you ...

The issue is that specifying exactly exception will not make code hard to maintain ... but all team members do not understand that Checked exception could be implemented like this:

public class FileUtils
{
    public void Write(string content)
        throws // Said that this function just throw some exception
    {        ...
    }
    
    public void WriteGeneric<T>(string content)
        throws // Said that this function just throw some exception
        where T: class     {
        ...
    }
}

In such case it could add support for error if user forgot to handle all error, it will feels like Rust (errors), Swift (errors), Java (checked exceptions) ...
I believe this information, regarding the specific exception, could be added by compiler as meta data

[jingkaimori]

If possible exceptions is unchecked, then nobody can tell whether a method throws exceptions, so any method caller should initialize their local variable use using keyword.

[jingkaimori]

with checked exception or nothrow, if a function turns out to throw no exception, using block in this function can remove outside try-catch clause, and variables declared with using could be optimized to usual cleanup invoke.

[eduarddejong]

The real problem is not Checked Exceptions, but actually the try-catch pattern in the first place.

Or to express it somewhat stronger:

1. introducing the try-catch pattern was the first design mistake, since there are better design options.
2. but given the fact they made that choice, not introducing Checked Exceptions was the second mistake,
   Try-catch unexpectedly interupts program flow, without forcing the caller to handle it, increasing the risk of the user dealing with an error instead of the developer.
   Checked exceptions cauld have prevented that, because they are part of a methods API and therefore force the developer to think longer about properly handling failures.

But the real solution is actually the way how a language like Rust solves it. making success or failure state part of the return type of a method, using a Result<T, E> type, based on the underlying concept of so called discriminated unions (but note Rust calls them enum).
This way the typing system of the language forces you to always handle failures, but also in a much more expressive, shorter way, using pattern matching based on return type (quite simular to C#'s way of pattern matching), instead of the old, cluncky try-catch block.

This however is basically too late for C#. I am aware of that.
I know in C# there are plans to introduce discriminated unions as wel, and that would be great for enough use cases.
But given the fact that most code will still be based on the existing exception model anyway, it would still be usefull if they introduced the checked exceptions, but in a way much like how nullable reference type checking works, just using compiler warnings, not compiler errors. And as an optional feature which you can enable/disable in the same way as well.

[geekley]

The advantage of checked exceptions is that thrown exceptions are part of the API, so you force callers to acknowledge it (either by handling or make it part of the caller method API). This helps prevent a lot of errors in code, but the way it's implemented in Java is not the best.

Ideally, the compiler would implicitly detect and declare for you the exact throws part of the signature with all possible specific exceptions your code might throw, without you needing to put it everywhere manually (similar to how var detects the type automatically). This way programmers won't end up obfuscating it with a generic throws Exception, and you get the benefit of static analysis. I think there's a good way to get the benefits of checked exceptions without the drawbacks. Here's my proposal:

1. If your method directly has uncaught throw new E(...); then throws E should automatically and implicitly be part of the method's signature, without requiring you to write it again manually. It's assumed you know and can see clearly that it throws E. You should only have to worry about the indirect exceptions that bubble up implicitly from called methods.
2. You should, by default, only really have to worry about those in API that's publicly visible outside the dll. You should be able to configure this with a compiler flag + code directive in a way similar to <Nullable> | #nullable.

// this flag is implied by default if absent
#exceptions public
...

// explicit `throw ...;` statements are always in API automatically

// with `may not throw`, no additional exceptions can bubble up
// this disallows even unhandled exceptions in code itself, like null ref, out of range, class cast, etc.
// as well as exceptions that may be thrown from method calls, as per their API
void f() may not throw { ... }

// allow only these additional exceptions to implicit bubble up
void f() may throw A or B or ... { ... }

// allow any exception to bubble up; `A|B|...` is implicitly auto-filled by compiler and is part of the API
// when you hover an `f()` call in IDE, it shows the specific types of exceptions it may throw
// as if it had been declared explicitly in the function signature
void f() may throw { ... }

// non-publicly visible: implies `may throw` by default; compiler auto-fills API
internal void f() { ... }

// visible outside dll: implies `may not throw` by default;
// coder must handle bubbling exceptions, or declare them to ensure public API is correct
public void f() { ... }

With #exceptions checked you can be more strict even internally:

// implies `may not throw` on any accessibility
// coder must always define bubbling exceptions (either explicitly per-exception, or with a `may throw`)
internal void f() { ... }

With #exceptions unchecked you can easily retain compatibility with previous code:

// exception is unspecified in public API,
// so if this dll is referenced by another project in a checked exception context,
// it assumes it `may throw Exception`
public void f() { ... }

Of course, the list of exceptions in the API never includes unforeseeable crashing errors that might happen, like stack overflow not thrown by user code, etc., since those aren't expected to be caught.

So, with this proposal, you'd get checked exceptions, but by default you don't even need to worry about adding may throw on most cases. You just worry about publicly visible API - where you should be doing a conscious choice about this anyways. And even when you add it, the compiler does most of the work for you so the API can be specific without needing you to manually list every possible exception yourself.

[geekley]

Making the exceptions part of the public contract is the versionability problem as described.

My argument is that it's a problem for app code using a lib, but a feature for lib code using another lib.

If they're not going to use this analyzer, why would they use this optional lang feature?

Analyzer or lang feature, what I want is for it to be trivial to discover, learn and set up. <Nullability> is trivial to set up. If it's some third-party analyzer from nuget, which lib authors may or may not know about, and figure out how to use, then it won't help lib users at large.

[CyrusNajmabadi]

My argument is that it's a problem for app code using a lib, but a feature for lib code using another lib.

Sorry, not sure how that helps my Linq question out. Are you saying Linq would not use this? How would it go about doing that?

[geekley]

Discriminated unions are the much better solution there, as that makes error conditions explicitly part of the return type.

For new fresh code, absolutely agree.
I'm thinking more about what to do for existing libs relying on an exception try/catch mechanism?

Linq

Sorry, I haven't thought much about this yet, so I think don't understand the question properly without some simple code example. I may not be experienced with the problem situation described.
Not sure if it could be solvable with something like a "throws when throws" contract of sorts or some sort of wrapper/annotation/whatever on delegate usages. Or if it's doable without API changes or not.

[geekley]

It's impossible to compose, impossible to describe via functional interfaces (delegates) and impossible to handle in the APIs themselves.

Could you elaborate with a simple example so I could understand better what you mean? If it's not trouble.

[HaloFour]

Here's an article that discusses checked exceptions with Java streams, and how to work around them:

https://www.oreilly.com/content/handling-checked-exceptions-in-java-streams/

In short, checked exceptions in composable APIs are nothing more than a nuisance with zero benefits.

[Rekkonnect]

The general motivation is to avoid exceptions, and only face them during prototyping where you're probably mishandling an API, or entering some dark documentation zones. This sounds utopic, but checked exceptions wouldn't truly add much value. The XML documentation containing the exceptions that may be thrown does a good enough job, except if you're not using Rider. Unfortunately as of the time of writing, VS doesn't seem to respect exception tags in members much, failing to show the description of the specific exception.

Overall, in the deployed product, you should avoid exceptions being thrown as much as possible, and design your API in an exception-free manner by offering types wrapping potential erroneous cases, or using null in case of failure to instantiate anything, while making sure you're throwing when the code behaves unexpectedly and logging those errors.

The takeaway is, with this feature you gain value by not following better architectural practices. By notifying the user about the types of exceptions to expect, you're telling them that they must play around funky exceptions when all they want is to use your API, and your API should fail to work when something's not right.

[mapokapo]

This idea of "this mistake is so common that it's not worth checking against" is very strange to me.
Yes, people get their accounts hacked all the time either because their password is not strong enough or it isn't stored in a secure location. But that's no reason to say "wow, people really don't care about our password requirements, let's just remove them". On the contrary I'd say it's even more reason to make the passwords even stricter and make it even harder to get your account hacked, by forcing you to make your account secure.

It would be like saying "memory leaks are extremely common, so instead of constantly reminding the programmer how memory unsafe their code is, we should just completely remove memory checking from our compiler because it distracts the programmer".

Ergonomics are important, but they should never be the number one concern for a language. If you want to make a language easier to use, you shouldn't make it simpler and start removing features - you should start making already existing features easier to use.
For now, I suppose we'd have to settle for a solution along the lines of @Daynvheur's suggestion, at least until something else surfaces.

[CyrusNajmabadi]

This idea of "this mistake is so common that it's not worth checking against" is very strange to me.

That's not really the argument though. The argument is that if you go down this route, you're more likely making things worse.

If you want to make a language easier to use, you shouldn't make it simpler and start removing features

Sure, but you also shouldn't add features that may be actively bad the majority of the time.

[FaustVX]

@mapokapo

On the contrary I'd say it's even more reason to make the passwords even stricter and make it even harder to get your account hacked, by forcing you to make your account secure.

No, absolutely not, the IT guys should provide a simpler solution, like the YubiKeys, FIDO, Password manager, ..., and "educate" the employees about that.

[mapokapo]

@CyrusNajmabadi
I see what you mean. From what I'm getting, it's not the checked exceptions themselves that are the problem, but the way they are used.
The biggest issue I can see with these types of checked exceptions is that you can't ignore them in the current context, leaving that work to a separate error handling module higher up. They take away control from the user, which forces bad habits.

But maybe I did not phrase myself correctly - what I am actually asking for is a standardized way to force method writers to let the user know if the method throws (and exactly which exception gets thrown), not force them to handle said exception.

[siegfriedpammer]

But maybe I did not phrase myself correctly - what I am actually asking for is a standardized way to force method writers to let the user know if the method throws (and exactly which exception gets thrown), not force them to handle said exception.

Sounds like XMLDoc and an analyzer that looks at each throw statement and the XMLDoc of used methods are a way to implement this.