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

121–130 of 318 posts

Re: Why checked exceptions failed

#121

Post by invalidname »

anonymoushn wrote: post #117
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…

It's weird to argue that null is how the hardware works. Many structs contain only bytes that are allowed to take on any value, so making them nullable takes extra space.

This is mentioned in the memory layout section in the post.

Re: Why checked exceptions failed

#122

Post by throwanem »

breadwinner wrote: post #54
EMM_386 wrote: post #21

Earlier quoted context omitted.

> Someone made a change in a function I was calling, and it started throwing a new exception. If it has nothing to do with your code, why not either let it bubble up the stack or try/finally it to do whatever clean-up you need to do before re-throwing it and letting it move on to a global logger or similar. If it is something you care about you can always catch the specific exception type and handle it. Maybe whoever…

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 why.

Re: Why checked exceptions failed

#123

Post by anonymoushn »

invalidname wrote: post #121
anonymoushn wrote: post #117

Earlier quoted context omitted.

It's weird to argue that null is how the hardware works. Many structs contain only bytes that are allowed to take on any value, so making them nullable takes extra space.

This is mentioned in the memory layout section in the post.

I'm not sure what "a marker" is and how to make it take 0 bits of storage.

Re: Why checked exceptions failed

#124

Post by mkleczek »

crabbone wrote: post #118
breadwinner wrote: post #93

Earlier quoted context omitted.

You need to help train your coworkers to write better code :) Point this thread out to them. Seriously, Java doesn't force bad programmers to write good code. It just enables good programmers to write good code.

That is not better code. Couple of try-catch-catch-catch-...-catch cases in a function that would otherwise be 2-3 lines long makes for an awful code. Also, imagine a situation when an iterator throws an exception. Or you wanted to write f(g()) but now you can't and have to do: try: T t = g(); catch E1: ... catch En: ... f(t); Now it takes a much greater effort for the reader to figure out what's going on. It's also…

This is only because you use exceptions incorrectly. You can (and should) write:

try {

  final var fResult = f(g());

  //do something with fResult
}

catch (E1 e) {...}

catch (En e) {...}

That's the main idea of exceptions in all languages: main flow is kept together and exceptional flows are separate.

Re: Why checked exceptions failed

#125

Post by invalidname »

anonymoushn wrote: post #123
invalidname wrote: post #121

Earlier quoted context omitted.

This is mentioned in the memory layout section in the post.

I'm not sure what "a marker" is and how to make it take 0 bits of storage.

This is an upcoming behavior in Valhalla which isn't yet a part of Java so there's nothing final. Currently Valhalla has primitive and value object types that determine identity behavior.

Re: Why checked exceptions failed

#126

Post by anonymoushn »

invalidname wrote: post #125
anonymoushn wrote: post #123

Earlier quoted context omitted.

I'm not sure what "a marker" is and how to make it take 0 bits of storage.

This is an upcoming behavior in Valhalla which isn't yet a part of Java so there's nothing final. Currently Valhalla has primitive and value object types that determine identity behavior.

You mean non-nullable object types then. Which are faster and take up less space because that's how the hardware works :)

Re: Why checked exceptions failed

#127

Post by crabbone »

breadwinner wrote: post #69
dbrueck wrote: post #66

Earlier quoted context omitted.

I stopped using Java a long time ago, and so I assume the language has gotten better since then, but early on at least it felt like Java almost took pride in making the developer jump through extra hoops. Compared to many other languages, using Java just made me feel tired. Checked exceptions - a feature that seems to be a cost to the developer 100% of the time while being a benefit far less than 1% of the time - is…

Some people say the same about strong typing. Like, why do I have to write down the type of every single parameter or variable? Java is making me jump through hoops! The point is, if you don't need the rigor of a strongly typed compiled language, there are other languages you can use. Perhaps a bash script is all you need.

You are very confused... "strong" in strong typing doesn't mean you have to write much or at all. Actually, it doesn't mean anything really. But, let's say, Haskell is probably at least as "strongly typed" as Java -- at least that's how most people understand that wording. And you don't have to write types in Haskell at all. It will be a nightmare (as if Haskell can be anything else, but even by the very low Haskell standards, it would still be a nightmare) code, but it will "work".

Until very recently, Java was just tedious, repetitive, high-entropy language, where you had to write everything multiple times.

Eg.:

    VeryLong variable = VeryLong();
In this expression, it's obvious what would be the most likely type of variable, but you still have to write it twice -- which is just worthless use of your time, especially when trying to read this very repetitive mess, and very easy to make a typo.

Recently, Java tried to improve this situation by allowing to omit types when the type inferred by default is the one you want. So, you need to write less. You also need to learn the inference rules, obviously, so it increases the cognitive load and rises expectations towards programmer's skill a bit. But, I think it's fair, since Java from a language for the brain-dead transformed into a language that requires more effort to master. While I'm not sure it's a positive change... this decision by Java developers kind of flies in the face of your argument:

No, it's not necessary to repeatedly spell out what you want your program to do. It's just boring and contributes nothing to the program's correctness. If anything, it only causes the programmer to lose focus and introduces mechanical errors that would've been totally avoidable, had the language was more terse.

Re: Why checked exceptions failed

#128

Post by javajosh »

kaba0 wrote: post #100
javajosh wrote: post #72

Earlier quoted context omitted.

>with the handler being locally found in a parent’s (recursively) method body Yeah, that doesn't sound disjoint /s

That’s the exact same thing as if you had a function call as the last statement in a functional call as a last statement, etc. Literally just popping off stackframes.

Popping 1 stack is a normal return; popping N stacks is precisely what is meant by "no-local (or disjoint) transfer of control".

Re: Why checked exceptions failed

#129

Post by crabbone »

wiseowise wrote: post #87
breadwinner wrote: post #69

Earlier quoted context omitted.

Some people say the same about strong typing. Like, why do I have to write down the type of every single parameter or variable? Java is making me jump through hoops! The point is, if you don't need the rigor of a strongly typed compiled language, there are other languages you can use. Perhaps a bash script is all you need.

Java is the only mainstream language with checked exceptions and checked exceptions are nowhere near usefulness of static typing. Following your logic, Java developers can now say “if you don’t like freedom of Java, use Rust/Haskell/Scala to validate everything at compile time”

Java is not the only language that has checked exceptions. C++ has them too, for example, but thanks god virtually nobody uses them in C++.

Re: Why checked exceptions failed

#130

Post by invalidname »

anonymoushn wrote: post #126
invalidname wrote: post #125

Earlier quoted context omitted.

This is an upcoming behavior in Valhalla which isn't yet a part of Java so there's nothing final. Currently Valhalla has primitive and value object types that determine identity behavior.

You mean non-nullable object types then. Which are faster and take up less space because that's how the hardware works :)

They're not faster for all cases. Near memory works great for some edge cases such as looping on an array of data in a block.

This is very much a special edge case. For many other non-benchmark situations this isn't so simple. If you add the overhead of memory copying and lack of identity things are more complex.

Post reply on HN