4 ms·

> The way I see it, simple code must be simple. If you want to do complex things, the language should allow you to do it some way. But not at the expense of eve

> The way I see it, simple code must be simple. If you want to do complex things, the language should allow you to do it some way. But not at the expense of everyday tasks. It's an elemental usability consideration. As you already mentioned, that ship has sailed the second you decided to use Java. Every function already has to be wrapped in `class`, which is obnoxious. > See? The mindset again. That question I can't understand. Actually I find it annoying as in "what kind of language is Java that you thing Kleenex functions are not allowed? does it thinks it's too good for my crappy functions?" My point wasn't celebrating boilerplate. It's about having a statically typed language. If it's too much to either add `throws Exception` to your function signature or to write a try {} catch {} block, then it must certainly already be too much to write `class MyClass { void myMethod() }`, no? > If there isn't a return value, I don't. You still have to write `void`, don't you? And checked exceptions are supposed to be something you want to force on callers of your code- like a return value. You don't want to return anything? Then return `void` and don't throw any checked exceptions. > Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions? Because it's part of your API. If you write: `int fooMethod(int input) {...}` Then you are saying "If you call `fooMethod` with an int you will get an int." If you always throw an exception on input == 3, then your API is now lying. You should either return a type that encodes the possibility of not being an int OR throw a (checked) InputWasThreeException, to be honest to your caller. Java is a poor language. Ideally there would be an ergonomic way to use a Result/Try type a la Rust and Scala. If such a thing existed, I would stop advocating for checked exceptions immediately.

TeMPOraL 6y ago
> Ideally there would be an ergonomic way to use a Result/Try type a la Rust and Scala. If such a thing existed, I would stop advocating for checked exceptions immediately. On that note: would it improve things, compared to checked exceptions that cause compile warnings if not handled? I'm currently dealing with similar problem on the C++ side - a codebase that's using a lot of tl::expected<> and "functional interface" instead of exceptions. And the more I work with it, the more I realize this introduces a lot more of boilerplate/book keeping to achieve the same goal exceptions would, with little to no benefit - except the possibility of error being visible in function signature. Which wouldn't be a problem for exceptions if "throws" in C++ wasn't broken.
- ragnese 6y ago
  The way Rust does it is not perfect, but it's the best I've used so far, IMO. Rust, if you are not familiar, has a special operator that let's you call a function that returns Result and automatically unwrap it and return early if it's an Error rather than Success. It will even automatically CONVERT the error for you if you've defined the proper trait implementation to convert the one error type into the other. So, in Rust the boilerplate happens ahead of time (implementing the conversion trait), outside of your function's internal logic. In your function you just write: fn foo(): Result<String, Error> { let f = something_that_can_faile()?; uses_the_success_value(f) } No try{}catch{}, no match statements, nothing. Just a question mark. Swift also strikes a nice compromise, IMO. It just has a throws tag like C++, except it actually works. I never considered a warning-level check for Java's checked exceptions. That sounds like a nice idea at first blush.

TeMPOraL 6y ago

> Ideally there would be an ergonomic way to use a Result/Try type a la Rust and Scala. If such a thing existed, I would stop advocating for checked exceptions immediately. On that note: would it improve things, compared to checked exceptions that cause compile warnings if not handled? I'm currently dealing with similar problem on the C++ side - a codebase that's using a lot of tl::expected<> and "functional interface" instead of exceptions. And the more I work with it, the more I realize this introduces a lot more of boilerplate/book keeping to achieve the same goal exceptions would, with little to no benefit - except the possibility of error being visible in function signature. Which wouldn't be a problem for exceptions if "throws" in C++ wasn't broken.

ragnese 6y ago
The way Rust does it is not perfect, but it's the best I've used so far, IMO. Rust, if you are not familiar, has a special operator that let's you call a function that returns Result and automatically unwrap it and return early if it's an Error rather than Success. It will even automatically CONVERT the error for you if you've defined the proper trait implementation to convert the one error type into the other. So, in Rust the boilerplate happens ahead of time (implementing the conversion trait), outside of your function's internal logic. In your function you just write: fn foo(): Result<String, Error> { let f = something_that_can_faile()?; uses_the_success_value(f) } No try{}catch{}, no match statements, nothing. Just a question mark. Swift also strikes a nice compromise, IMO. It just has a throws tag like C++, except it actually works. I never considered a warning-level check for Java's checked exceptions. That sounds like a nice idea at first blush.