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

161–170 of 318 posts

Re: Why checked exceptions failed

#161

Post by necovek »

ailef wrote: post #4
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.

This is indeed the supported way to do it.

Thanks for confirming as I am not familiar with Java, but good to know it does make sense. As such, I am not sure what did the original author complain about because that's perfectly sufficient language support.

Re: Why checked exceptions failed

#162

Post by _a_a_a_ »

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…

Each 'leaf' statement of language should have a definite and finite list of exceptions that it can throw.

Each non-leaf statement is a composition of leaf statements. Therefore every exception can be determined, and that's our checked exceptions would work; work at the exceptions and check they match the list.

Therefore even without checked exceptions the compiler could provide the exceptions you want and you can check them or not if you please, so get the best of both worlds. All without forcing people to give an explicit list of exceptions everywhere. Forcing checked exceptions is not going to be popular, and much of the time is counter-productive.

Also someone broke your Liskof Substitution Principle which may be your bigger problem.

Re: Why checked exceptions failed

#163

Post by mkleczek »

im3w1l wrote: post #152
mkleczek wrote: post #148

Earlier quoted context omitted.

Yes - that's one of the issues with structured exception handling. Relying only on exception type itself is not enough as information is lost (ie. the actual source of exception)

Crazy idea: Maybe it would be helpful if we could label operations, and catch by either label or type or (label, type) . The we could centralize error handling without losing anything.

While deceptive at first... Just try to imagine how "extract method" refactoring would work...

Re: Why checked exceptions failed

#164

Post by joexner »

throwanem wrote: post #122
breadwinner wrote: post #54

Earlier quoted context omitted.

Imagine that the functionality implemented by your method is very important. This functionality should not be needlessly aborted. If so you want to be aware of errors you can recover from, correct? This is why checked exceptions are helpful. It gives you a guaranteed-by-compiler list of exceptions and you can decide which of those you should recover from.

Or I can catch any exception out of the codepath I'm concerned about, examine it to see if it's one of the known set of exceptions I intend to handle, and then either do so or rethrow it. If there's a benefit to compile-time exception checking over this method, I have to admit I don't see it. But I've also never worked deeply enough with Java to be familiar with the nuances of its exception handling, so that may be w…

Checked exceptions give you, essentially, syntactic sugar for handling just a few kinds of exceptions and re-throwing the rest.

It's useful when there are one or two error cases you want to retry or handle specially, but you want to just barf any other error up the stack. It's a specific use case but it's prevalent.

The downside is that sugar can only separate your error conditions by Java type. If everything is just an Exception, you'll have to use sort out your error cases in code.

Re: Why checked exceptions failed

#165

Post by xen0 »

specialist wrote: post #133
xen0 wrote: post #106

Earlier quoted context omitted.

I don't think that helps? If, as is kind of the point of RAII, your constructors do some initialization and that initialization may fail, then: If you have a single object that may fail to construct then maintaining it in scope for the catch block doesn't make sense; it's not initialized. If you have several, then you still can't maintain them in scope, because you don't know which ones are actually valid. Yes there…

I misspoke. Ignoring the syntax for a moment, I want scoping to behave like this pseudo-code. So that the catch and finally blocks are lexically nested within the parent try block. try { OutputStream out = ... ... // Must be at end of try block catch ExceptionA, Exception B { ... } catch Exception C { ... } finally { ... } } // end of try Maybe even allow catch and finally to allow single expression in addition to bl…

Right, but if constructing OutputStream throws ExceptionA, you shouldn't have it in scope; it's not something you can use.

Re: Why checked exceptions failed

#166

Post by throwanem »

joexner wrote: post #164
throwanem wrote: post #122

Earlier quoted context omitted.

Or I can catch any exception out of the codepath I'm concerned about, examine it to see if it's one of the known set of exceptions I intend to handle, and then either do so or rethrow it. If there's a benefit to compile-time exception checking over this method, I have to admit I don't see it. But I've also never worked deeply enough with Java to be familiar with the nuances of its exception handling, so that may be w…

Checked exceptions give you, essentially, syntactic sugar for handling just a few kinds of exceptions and re-throwing the rest. It's useful when there are one or two error cases you want to retry or handle specially, but you want to just barf any other error up the stack. It's a specific use case but it's prevalent. The downside is that sugar can only separate your error conditions by Java type. If everything is just…

By the sound of it, that's more like syntactic salt, or maybe syntactic thallium - `else { throw error; }` seems much simpler by comparison.

Being able to know what exceptions can possibly be thrown at a given point is useful, but seems like a problem better solved through static analysis than by requiring annotations.

Re: Why checked exceptions failed

#167

Post by xen0 »

breadwinner wrote: post #107
xen0 wrote: post #99

Earlier quoted context omitted.

And a lack of checked exceptions means good programmers can't write good code? So good code may only be written in Java? No... I don't think so. Checked Exceptions are at best, just a 'hey, are you sure that's right thing to do here?' and at worst, an additional source of rigidity in your code that blows up the scale of a minor change.

> And a lack of checked exceptions means good programmers can't write good code? Right, and that was my point at the top post in this thread.

Wait, you seriously hold that position!? As in, only Java permits good code?

Re: Why checked exceptions failed

#168

Post by interlocutor »

crabbone wrote: post #112
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…

This is very simplistic view of the problem. This completely glosses over modularity, ABI, performance optimizations... just to name a few. How are you going to write generic functions that take functions as arguments and re-throw the errors thrown by these functions, if you use checked exceptions? Will you require that the acceptable functions only throw exceptions that you like? -- Then your generic function is clo…

> write generic functions that take functions as arguments and re-throw the errors thrown by these functions

There is a philosophy that applies here: simple things should be simple, complex things should be possible. The scenario you're mentioning is not common enough that the language design should be centered around it.

Re: Why checked exceptions failed

#169

Post by breadwinner »

xen0 wrote: post #167
breadwinner wrote: post #107

Earlier quoted context omitted.

> And a lack of checked exceptions means good programmers can't write good code? Right, and that was my point at the top post in this thread.

Wait, you seriously hold that position!? As in, only Java permits good code?

Each language has its strengths and weaknesses. In the case of exceptions Java gets it right, C# doesn't. There are other aspects that C# does better than Java.

Re: Why checked exceptions failed

#170

Post by scarface_74 »

invalidname wrote: post #88
funnymony wrote: post #82

Earlier quoted context omitted.

Yes, grep and nuclear reactor controller, and your gui grep are applications. They all use library for file reading. As author of file reading library you don’t know how critical is the failure to open a file or how it should be handled. My point was that You know those things only at application level. So it feels a bit misguided to decide at library level which failures are important. (I.e. which are checked vs whi…

The library knows which are crucial issues that warrant your attention. A checked exception is a regular exception, it's just one that you can't miss and must either handle or propagate. As a library author if you don't feel you need it then don't use it. It's optional. That's the beauty of it. > First thought: documentation. (which is required for both, checked and unchecked exceptions). Documentation > But overall,…

> The library knows which are crucial issues that warrant your attention

The library author can’t know what’s crucial in the context of my program.

Post reply on HN