Replies: 12 comments 102 replies
|
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 |
|
It is unlikely we'd reverse ourselves on such a longstanding and deep design issue. |
|
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. |
|
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
A good practise is to write code, which is easy to reason about it’s behaviour. 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. |
|
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:
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!! |
|
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 |
It's an absolute necessity to work with any kind of functional programming.
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. |
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.
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
|
It's how the language allows you to interact with them that matters. If composing over exceptions was similar to working with 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.
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. |
|
How would you handle the lack of union types? |
EDIT: Disregard this @HaloFour, I see you have broadly already answered another one that had the same thought, I will leave it here because this adds examples that might provide more clarity on his question. If you where to handle that in the same Type specific way don't that bring the same issue as you mention? public Parsed parseInput(...) throws IllegalArgumentException, SomeOtherException {}In order to be just as specific, would you not have to: public OneOf<Parsed, InvalidArgumentError, SomeOtherError> ParseInput(...) {}I know you could do: public OneOf<Parsed, Error> ParseInput(...) {}But would that not be more equal to just do: public Parsed parseInput(...) throws Exception {}And therefor not really communicate all the error cases well, which is the ask here?... And if that is correct, adding another Error type would bring the same issues right? public Parsed parseInput(...) throws IllegalArgumentException, SomeOtherException, SomeNewException {}And public OneOf<Parsed, InvalidArgumentError, SomeOtherError, SomeNewError> ParseInput(...) {}Genuinely asking because I can't see how a union type would not have the same compatibility issues... Handling it this way though means that people are free to manage this in their own way, which is IMO a huge advantage over a "language feature"... |
|
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.
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. 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: and the repository to the Checked Exception extension on C# using Roslyn |
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. |
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.
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.
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#.
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 |
|
Thank you for your useful comments.
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.
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. |
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. |
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 |
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) ... |
|
If possible exceptions is unchecked, then nobody can tell whether a method throws exceptions, so any method caller should initialize their local variable use |
|
with checked exception or |
|
The real problem is not Checked Exceptions, but actually the try-catch pattern in the first place. Or to express it somewhat stronger:
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 however is basically too late for C#. I am aware of that. |
|
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
// 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 // 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 // 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 |
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? |
For new fresh code, absolutely agree.
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. |
Could you elaborate with a simple example so I could understand better what you mean? If it's not trouble. |
|
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. |
Lippert’s post on vexing exceptions highlights the importance of distinguishing exception types that should be contractually exposed from those that should not, whether the mechanism is manual or automatic. This seems like a natural use case for analyzers such as Portia.Roslyn.CheckedException. If (and only if) such an analyzer becomes smart and widely adopted, that would be a strong signal that the idea is viable enough to consider as a first‑class feature. Of course, analyzers are inherently less discoverable than optional language features — nullable reference types are a good example of how compiler‑supported opt‑in features gain far more visibility. |
|
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 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. |
|
That's basically a complete and total reimagining of the .NET ecosystem. Being the solution doesn't make it not intractable. Analyzers or the like are far from perfect, but they're also many, many orders of magnitude less effort. |
It's only a solution if it's actually viable for the ecosystem. Virtually all requests are possible. But those that require boiling hte entire ocean stand very little chance of happening :) |
|
It's obviously not happening in C#/dotnet. But not because it's inherently impossible. Pointing to algebraic effects, which have entire languages and runtimes built specifically around them, gives the necessary background. @HaloFour , analyzers don't solve this, as you explained yourself. We need the metadata to be emitted on the methods. I'm prototyping a source generator that does this from a DSL, but even when I can load up the generated C# with metadata there are significant obstacles. |
This the csharplang repo. IT's for discussions precisely around c#/dotnet :). For general conversations about programming languages/capabilities/etc., i'd recommend other locations. :) |
How? >.<... I can't even wrap my brain around how this could actually be achieved given compiler support and meta data realistically... Just a simple problem as you mention: public void MaybeIThrow(IMyInterface foo) {
foo.Execute();
}Brings a unimaginable amount of trouble along... Next thing is when a assembly "Foo" depends on "System.Text, v1.0.0"... Then there is async and other stuff which you also mention... But if we go absolutely crazy... what about: public void MaybeIThrow(IMyInterface foo) {
var exception = Expression.Constant(new InvalidOperationException(""));
var @throw = Expression.Throw(exceptionInstance);
...
Expression<Func<string>> lambda = Expression.Lambda<Func>(fullImplExpression);
Func compiledMethod = lambda.Compile();
compiledMethod();
}And... public void MaybeIThrow(IMyInterface foo) {
Assembly assembly = loadContext.LoadFromAssemblyPath(assemblyPath);
Type? target = assembly.GetType("Type.Full.Name");
MethodInfo? method = targetType.GetMethod("Execute", ...);
method.Invoke(...);
}As i see those, there is simply no solution possible for solving those even with a compiler emitting thrown exceptions as meta data, what should it emit here??? - And given that I can't see a solution for a compiler - there is no hope for a Analyzer either as I see it, correct???, and if things break down that quickly, will it ever be worth the effort?... I think there are features I would rather have the team work on... So spitballing/brainstorming. If any focus should be given this IMO, it should be on how to bring better information forward, given we can already provide this in XML comments, I would perhaps lean towards providing better assistance towards writing this into the XML documentation with more automation, perhaps here an analyzer would be useful, what might be more useful is if we could emit generated documentation, similar to when you use /// <inheritdoc />... Taking it further, if we could augment the documentation with "custom enhancers" (similar in concept to how you can use source generators)... Then this could be trialed outside of the team... But maybe that is just a crazy idea??? And yes, this would have a bunch of caveats, the same as above and more, but allot of Developers are probably a bit lazy when it comes to writing documentation for their stuff, and I don't blame them, it's boring after all, so making it easier might improve what people are willing to write, e.g. If I could just add a /// <exceptions /> node to my docs, then when I compile the documentation engine would do some steps to see what it might need to fill into that section (And it would only be able to collect info from said method + perhaps the immediate call tree inside the project, from references it would have to rely on documentation from there, if nothing it would not be able to infer anything, but nor would I), that would be far less effort than having to provide each type of exception and keeping that up to date even thought that would give better explanations. |
|
The ergonomics of this design space has been solved by algebraic effects (e.g. Koka, Verse). A lot of the objections I see up above (e.g. higher-order functions) are addressed by the literature on AE from the past decade. Looks like Epic will be pushing Verse heavily with UE6, so a lot of people are soon going to encounter effects head-on. @geekley , you were on your way to re-invent a subset of AE. Let's explore what this would look like in C# for exception propagation alone. The syntax below is provisional and only intended to illustrate the model. This would track only exceptions participating in the checked-exception system; exceptions originating from the runtime remain untracked under normal C# semantics. Effect parameters such as This is also separate from enforcement policy. The compiler can track and propagate exception effects regardless of whether an unhandled effect is ignored, produces a warning, or is an error. Start with the simple case. Assume string ReadFile(string path)
throws IOException;A caller propagates that effect: Config LoadConfig(string path)
throws IOException
{
return Parse(ReadFile(path));
}The compiler can infer the effect from the implementation. Intermediate callers do not need to explicitly acknowledge or handle every exception; they can simply acquire the inferred effect row. Handling the exception removes it from the propagated effect row: Config LoadConfig(string path)
{
try
{
return Parse(ReadFile(path));
}
catch (IOException)
{
return Config.Default;
}
}Exception inheritance works naturally here. An effect for A narrower catch does not: string ReadConfig(string path)
throws IOException
{
try
{
return ReadFile(path);
}
catch (FileNotFoundException)
{
return "";
}
}
Multiple unrelated exceptions form an effect row: Config LoadConfig(string path)
throws IOException, FormatException;Rows can be normalized through exception inheritance. For public API contracts, declared effects can act as upper bounds. An implementation declared The next problem is delayed execution. Suppose we store a computation to run later: class Lazy<T, effect E>
{
private Func<T> throws E factory;
T Value() throws E;
}Constructing More generally, when an effectful delegate escapes its immediate call site and is stored for later execution, that effect information needs to survive with the stored value. Exposing an effect parameter on the enclosing type is one way to do that. That leads naturally to higher-order functions: TResult Apply<T, TResult, effect E>(
T value,
Func<T, TResult> throws E func)
throws E;
LINQ combines both problems: higher-order functions and delayed execution. var contents = paths.Select(ReadFile);
Conceptually, and ignoring the details of the existing iterator interfaces: interface IEnumerable<out T, effect E>
{
IEnumerator<T, E> GetEnumerator();
}
interface IEnumerator<out T, effect E>
{
bool MoveNext() throws E;
}The point is not that
A terminal operation exposes the accumulated effects during enumeration: T[] ToArray<T, effect E>(
this IEnumerable<T, E> source)
throws E;So: var contents =
paths
.Select(ReadFile)
.ToArray();propagates the tracked exceptions from The same general model applies to Interfaces introduce another abstraction boundary: interface IReader
{
string Read() throws IOException;
}Here the interface contract provides an upper bound. An implementation may have the same or a narrower effect row, but cannot introduce tracked effects outside that contract. If preserving an implementation-specific effect is itself part of the abstraction, the interface can be effect-polymorphic: interface IReader<effect E>
{
string Read() throws E;
}Again, Inheritance follows the same substitutability rule: an override may narrow the effects promised by the base member, but not widen them. This is also where analyzer-only approaches become limited. The information has to survive through delegates, stored computations, interfaces and assembly boundaries, so downstream compilations need the effect information in metadata. Existing assemblies would not all need to acquire that metadata at once. An imported method without effect metadata can conservatively be treated as: string LegacyMethod() throws Exception;Here This preserves soundness at the cost of precision. In practice, useful adoption would likely require early annotations for much of the BCL, external annotation metadata, or some other mechanism for supplying more precise contracts for existing libraries. Precision improves as more APIs acquire effect information. Public and protected effect information would become part of the API contract. Inference is useful within an implementation, but changing a published method from Nullable reference types provide a useful precedent for the migration strategy: additional static type information can be inferred, emitted in metadata, and introduced incrementally while existing assemblies remain usable with reduced precision. The legacy-boundary semantics need not be identical to NRT; the relevant precedent is gradual, metadata-backed static typing over an existing ecosystem. None of this requires union types or This isn't a weekend project. It touches the type system, delegates, LINQ, iterators, Sources / prior art
|
and others
Uh oh!
There was an error while loading. Please reload this page.
What about Checked Exceptions in C# like Java?
I think it would be helpful to expect all behaviors of the method/object.
It will enforce that every method who calls FileUtils.Write should do it within a try..catch.. statement.
All reactions