4 ms·
Afaik, no language as great of exceptional handling as Java. I prefer Go but I have to admit, Java's checked exception handling is amazing.
by guideamigo_com 3y ago
Afaik, no language as great of exceptional handling as Java.
I prefer Go but I have to admit, Java's checked exception handling is amazing.
- iopq 3y agoChecked exceptions are gross, they get in the way when you're prototyping, and you end up just ignoring them anyway (since you're prototyping)
- quelltext 3y agoThe ergonomics of checked exceptions may be debatable but compared to golangs explicit error handling at essentially each function call is definitely worse.
- peterashford 3y agoYeah, I've got a lot of Java experience and a wee bit of Go language experience and I agree with you. I like Go in almost every way except for it's error handling. It's just wrong to have to check every goddam function one by one
- pkolaczk 3y agoI guess that's the reason why most Java programs I use cannot do proper user-facing error messages. Because it is so easy to just ignore error handling. The exception will be caught by the top-level, right? This is how almost every Java cli tool prints a stacktrace on even most trivial user errors like file not found. Having to deal with errors and forcing the developer to do proper error handling is a good thing.
- ArandomAccount2 3y ago[dead]
- guideamigo_com 3y agoI don't mind Go's errors. I do mind the complete lack of hierarchy in that. Java's exceptions are hierarchical. I can create an exception that specializes from `IOException` and that I feel is really powerful. Go added this half-baked and much later. So, most FOSS libraries don't support it yet.
- pkolaczk 3y agoBoth Java checked and unchecked exceptions are inferior to signaling errors by return values like Go/Rust/Haskell do. Exceptions are not composable, cannot be generic, and it is not visible in the source code which lines can throw, so every line is a potential branching point.
- osigurdson 3y agoI don't think the jury will ever return on this topic.
- wscp-dev 3y agoThat is an extremely debatable topic. Which is why kotlin completely ignores checked exceptions. Frankly, Id rather have a result and optional/nullable type like in rust/kotlin than deal with exceptions in any capacity.
- wice 3y agoKotlin’s decision to make every exception runtime is the main reason I don’t use Kotlin. It’s especially baffling that they realized the issue with implicit nullability and got rid of it (though not with Java methods, which opens another can of worms), then went and intoduced implicit “exceptionality”. The correct way to deal with Java’s checked exceptions would have been introducing a Result type, or, preferably, type algebra, like in TypeScript, so something like: fun openFile(fileName: String): File | FileNotFoundException {…} Then you could handle it similarly to null: val content: String | FileNotFoundException = openFile(“myfile.txt”).?read() …then you have to do a check before you use content as a String… or val content: String = openFile(“myfile.txt”)?.read() ?: “File not found” (There could also be other possible ways of handling the exception, like return on exception, jump to a handling block, and so on.) In fact, null should be treated as an exceptional value the same way all exceptions should be.
- thewix 3y agoThis would be my preference. I like `Either`or some other container type, but a simple union that makes exceptions explicit works also.