Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why checked exceptions failed

borretti.me

Post reply on HN
Print view View original

11–20 of 318 posts

Re: Why checked exceptions failed

#11

Post by thewix »

PretzelPirate wrote: post #8
necovek wrote: post #2

I am surprised an even more obvious interface definition of public interface ExampleInterface { void foo() throws IOException, AnotherException; } was not covered: is this also not supported? That would solve a lot of use cases if inheritance is respected.

Wouldn't it still be a problem? By putting "throws [Exception List]" in the interface, the interface making assumptions about the implementation details of every potential implementation. The interface can't know every exception that an implementation might throw, and using your example, some implementations may not use IP at all and won't throw those exceptions. It seems like you'd end up needing to list every possi…

Exceptions should absolutely be a part of an interface and it stops you from leaking implementation details. If I have an IRepository interface then none of the methods should ever throw SqlException, HttpException, or anything like that. You'd map them to something else. Exceptions in most languages are implicitly part of the contract, and not having consistent ones on an interface breaks Liskov's Substitution Principle.

Re: Why checked exceptions failed

#12

Post by invalidname »

My opinion is the exact opposite see https://debugagent.com/everything-bad-in-java-is-good-for-yo...

Checked exceptions are unpopular since no one likes responsibility. But they are great when used right. Calls that must have proper cleanup after them e.g. SQL, IO are checked. The fact that this must be communicated via interfaces is hugely important.

There are "weird" problems such as stream close() throwing a checked exception. That's an API misbehavior that has a workaround thanks to try-with-resources.

Re: Why checked exceptions failed

#13

Post by vmaurin »

redeeman wrote: post #6

> Can I specify that implementations of foo can throw no, some, or all exceptions? just because theres the possibility of a throw in the signature, does not mean it has to be done in a concrete implementation, and if implementations are really to be exchangable, it has to be handled in case implementation changes. > What would it even mean to write something like throws *? Roughly similar to "throws Exception" or "th…

For checked exception, as you mention, "throws *" is throws Exception, then people can refine it on implementation.

As many language feature, checked exception are often misused and/or misunderstood. Too many time I have seen people blindly propagating checked exception above, and you end up having a controller method exposing a SQLException. Then for sure, it is better to use unchecked exceptions overall

Re: Why checked exceptions failed

#14

Post by breadwinner »

I have extensive experience in C# as well as Java. It is bizarre to suggest that checked exceptions have failed. It is unchecked exceptions that have failed. It is the biggest flaw of C#, in fact. Why?

As an example, I wrote some very good C# code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash.

The list of recoverable exceptions that can be thrown by a method should be part of the contract. It should be written down by the programmer, and enforced by the compiler. If not, then to avoid crashing you would have to catch the root Exception class, which everyone agrees is a bad idea.

More on checked vs unchecked exceptions here: https://forum.dlang.org/thread/hxhjcchsulqejwxywfbn@forum.dl...

Re: Why checked exceptions failed

#15

Post by grumbel »

PretzelPirate wrote: post #8
necovek wrote: post #2

I am surprised an even more obvious interface definition of public interface ExampleInterface { void foo() throws IOException, AnotherException; } was not covered: is this also not supported? That would solve a lot of use cases if inheritance is respected.

Wouldn't it still be a problem? By putting "throws [Exception List]" in the interface, the interface making assumptions about the implementation details of every potential implementation. The interface can't know every exception that an implementation might throw, and using your example, some implementations may not use IP at all and won't throw those exceptions. It seems like you'd end up needing to list every possi…

> the interface making assumptions about the implementation details of every potential implementation.

No, as you'd force the implementation to catch their implementation specific exceptions and rethrow them in the way defined by the interface.

That's really the crux of it, when I call foo(), I expect to see a FooException when something goes wrong, since that's the only one I can meaningful react to. If I get an ImplementationDetailException that I never heard from and that isn't specified in the interface, how am I supposed to react to that in a meaningful way?

If exception are supposed to be used for error handling, you have to actually report and handle them in a well specified manner, you can't just treat them as a slightly less crashy version of a SIGSEGV.

Re: Why checked exceptions failed

#16

Post by scarface_74 »

breadwinner wrote: post #14

I have extensive experience in C# as well as Java. It is bizarre to suggest that checked exceptions have failed. It is unchecked exceptions that have failed. It is the biggest flaw of C#, in fact. Why? As an example, I wrote some very good C# code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing…

Catching the root exception is not a bad idea. If you had caught the new exception what would you have done with it?

Most of the time, it’s either catch the exception, log it in a central logging system keep moving and have a central alerting system or catch the exception log it and crash the program.

Re: Why checked exceptions failed

#17

Post by he0001 »

Checked exceptions are great. But they were abandoned due to the functional paradigm so now it’s cumbersome to use them. Errors should be first class of any language and not bolted on as some sort of afterthought, language or design. Errors are something that occurs in real life and should be handled as such. Unchecked errors are a pain to deal with and always are unexpected which you need to dig into the code to see if they are thrown. This is a huge issue for me. I believe that Java should and could make them more easier to use by adding language support to transform them.

Re: Why checked exceptions failed

#18

Post by cubefox »

While I broadly agree with this, the author doesn't appear to go far enough himself.

> Functional error handling, using Option and Result types, is rapidly becoming the standard operating procedure in essentially every language, because it relies on nothing but values and types. They are more of the same, and so they fit right into the existing language machinery.

I agree that Optional types are better than checked exceptions, but they are worse than union types. A function with the union return type String|Error (read: String or Error) is allowed to return another function with return type String. Similarly, a function which accepts the type String|Error as a parameter also accepts parameters of type String. With Option types this doesn't work. Option and String are incompatible types, so code has to be rewritten if the types change.

Personally, I would go so far as to say that union types should replace exceptions in general, checked or unchecked, as well as any implicit nullabiliy, which can be replaced with the explicit union type Foo|Null.

(Although some special syntax for handling Foo|Exception or Foo|Null is probably a good idea, as "error" and "nothing" are pretty general categories.)

Re: Why checked exceptions failed

#19

Post by croes »

breadwinner wrote: post #14

I have extensive experience in C# as well as Java. It is bizarre to suggest that checked exceptions have failed. It is unchecked exceptions that have failed. It is the biggest flaw of C#, in fact. Why? As an example, I wrote some very good C# code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing…

>you would have to catch the root Exception class, which everyone agrees is a bad idea.

It's a bad idea to catch an unexpected exception?

Re: Why checked exceptions failed

#20

Post by scarface_74 »

invalidname wrote: post #12

My opinion is the exact opposite see https://debugagent.com/everything-bad-in-java-is-good-for-yo... Checked exceptions are unpopular since no one likes responsibility. But they are great when used right. Calls that must have proper cleanup after them e.g. SQL, IO are checked. The fact that this must be communicated via interfaces is hugely important. There are "weird" problems such as stream close() throwing a check…

> Calls that must have proper cleanup after them e.g. SQL, IO are checked.

Why? In C# you use a “using” block and whether your code exits the using block successfully or with an exception, the cleanup is automatic.

RAII has been around at least since the 80s with C++.

Post reply on HN