Hacker News Reader

Comment by breadwinner | Hacker News Reader

One area where C# really messed up is exception handling.

See https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

They intentionally chose to not have checked exceptions though, and people have different opinions on it. They believed that people would just catch Exception most of the time anyway instead of selecting on a very specific type (which is often how it works, in web apps anyway.)

https://www.artima.com/articles/the-trouble-with-checked-exc...

> They believed that people would just catch Exception most of the time anyway

Their belief was wrong. Microsoft now recommends against catching Exception.

The article you linked to is addressed at the bottom of this article: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

Java streams and a lot of other APIs are extremely ugly because of checked exceptions. Conversely, LINQ and delegates and a lot of other syntax is far cleaner in C#.

Your linked blog is pretty wild. Only throw RuntimeExceptions to crash? Why not just Exit if that's the proper thing to do?

If you treat all C# exceptions as RuntimeExceptions, then it satisfies the blog anyhow.

> Why not just Exit if that's the proper thing to do?

Because you won't get a stack trace.

Checked exceptions could still work across lambdas. Scala is doing research there: https://docs.scala-lang.org/scala3/reference/experimental/ca...

One of the original lambda proposals for Java - the one from Neal Gafter - also had checked exceptions.

The problem is that you then need a way to capture exception specifications as generic type parameters to properly propagate contracts, which complicates the type system quite a bit. Which is why Java ultimately went with the much simpler proposal that didn't even try to tackle this.

Yes I'm well aware, but that is uniquely a Java problem. With a sufficiently strong type system, like the one in Scala, you can easily make checked exceptions work across higher order functions.

Side effects are not allowed in functional style programming. Exceptions are side effects, it doesn't matter whether they are checked or unchecked exceptions.

https://jessewarden.com/2021/07/why-functional-programmers-a...

While composing methods in stream style is convenient, methods that can throw exceptions warrant more careful coding, so convenience should not always be the priority.

Exceptions are not side effects since no state mutation occurs.

If you really want to see everything through the FP lens, exceptions are exactly like Result<T, E> with implicit do-notation.

I don't know that I'd say "messed up", but I do wish C# had checked exceptions. I strongly believe that they are superior to non-checked exceptions, basically static type signatures but for error handling. It's a real pity that everything after Java seems to have abandoned the idea.

Java itself has basically abandoned the idea, or at least the ecosystem at large has. Checked exceptions are a decent idea but Java's implementation sucks. It needs to be a lot more automatic or something

> Java itself has basically abandoned the idea

Some Java developers may have, due mostly to misinformation from the .NET camp.

IIRC all previous conversations about checked exceptions here ended up with the swift conclusion that they are heavily discouraged throughout Java code.

> they are heavily discouraged throughout Java code

That's so ignorant. Read the article please.

Let's revisit past conversations:

- https://news.ycombinator.com/item?id=43226624

- https://news.ycombinator.com/item?id=43584056

- https://news.ycombinator.com/item?id=36736326

And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between error and panic model. I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.

> I'm not sure what you found in (checked) exceptions.

I could copy/paste the entire article here... but it would be easier if you could take a gander: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...

Summary:

Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library.

More crashy code: If a method starts throwing a new exception, you might not realize you need to update your error handling.

Dead code: If a method stops throwing an exception, old catch blocks may linger, becoming dead code.

None of those arguments are convincing. In many cases, you can't handle errors more reasonably than just crashing or telling the user something went wrong. Java has RuntimeExceptions, which do not have to be declared in the function signature. Division by zero, or trying to index an array out of bounds, and the dreaded NullPointerException, are some examples of RuntimeExceptions.

What about the ones you can recover from? You don't want to crash the entire application every time there's an exception!

You usually wouldn’t crash the entire application, the request that causes the issue will return a 500 error. (Or equivalents for non-web environments.)

Some exceptions are not recoverable and may cause 500 error. Others such as FileNotFound are recoverable, for example by reading the file from an alternate location.

> You have no compiler-enforced way to know what exceptions might be thrown from a method or library.

Always assume exceptions will be thrown from a method or library.

Which ones? That's the issue.

> I'd prefer to use that one as it actually reduces boilerplate and improves correctness, the opposite to the outcome of using checked exceptions.

Reducing boilerplate is not a valuable goal in and of itself. The question is, does the boilerplate buy you something? I think that with checked exceptions it does. Having an explicit type signature for what errors a function can raise improves correctness a great deal because the compiler can enforce the contracts of those functions.

I agree that the Rust approach is good too, though I don't agree it has any strong advantages over the way Java does things. Both approaches are equally respectable in my view.

Reply on news.ycombinator.com