> 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.
The simple code must be simple, but not simpler than that. For exploratory code it's fine to ignore the failure paths; for production code, it isn't. Java's checked exceptions force you to operate in the "production code" mode, so the language isn't super-convenient for prototyping. I'd personally like all exceptions to be checked, but with "checked exceptions as warnings" mode by default - with an understanding that production code will be built with "warnings = errors" switch.
> If there isn't a return value, I don't.
What if there isn't a return value in the success case, but there is one in case of failure (i.e. the error)?
> Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions?
You don't need, but you probably want them. Unchecked exceptions are invisible in the method's signature; to get a list of exceptions you need to handle, you'd have to dig through implementations of everything downstream of your method.
There's a trend across different languages to use algebraic data types (Result, Expected, etc.) to allow returning a valid result XOR an error, which by design make you deal with a possible error if you want to get the result. Exceptions are essentially the same thing, except with less boilerplate (in C++/Java-style language), but you need checked ones to actually force the programmer to deal with failure modes.
Force is the key word for me. It's the "we know better than you" language designer mindset. My point is that if they really knew better, they wouldn't be making this anti-usability calls.
Edit: OK, someone is downvoting ALL comments because opinions. No more comments by me. I'll delete everything that I can. Seriously, if someone doesn't want to read opposing opinions, I guess it's their right. And mine is to STFU, for good.
Edit2: hey TeMPOraL, I don't care too much about that, it's the feeling of being in a community where someone thinks this is an acceptable behaviour.
I've been writing here for very long. But this is getting ridiculous. Anything that is minimally controversial gets downvoted. And the thing is that I am already censoring myself a lot.
> It doesn't make much of a difference if Sun, the authors of the language, or Sun, the authors of the runtime, is screwing me.
But it matters for me, the programmer using modules written by other co-workers and third party libraries, that I'm made aware of what can fail and at what point, when I'm using these modules/libraries. It also matters to me that my tools (e.g. the compiler) force me to handle these cases correctly, or at least warn me when I'm not - lest I ship broken code through carelessness or ignorance.
Quality Sun's API design is a different issue. This is about giving people tools to express and enforce error handling semantics in software they design.
EDIT:
> Edit: OK, someone is downvoting because opinions. No more comments by me.
It's good to not be attached to imaginary Internet points. They come and go and ultimately don't matter much. And FWIW, bad downvotes often get countered, and the score of a given comment settles to something reasonable over time.
Java generics aren't powerful enough; an exception signature is a union type whose size varies. There's no way to declare that a method's exception signature depends on the signatures of the arguments for each call. No way to take a lambda or method reference and throw whatever that could throw. Checking is nice but IMHO not worth giving up higher-order functions.
The simple code must be simple, but not simpler than that. For exploratory code it's fine to ignore the failure paths; for production code, it isn't. Java's checked exceptions force you to operate in the "production code" mode, so the language isn't super-convenient for prototyping. I'd personally like all exceptions to be checked, but with "checked exceptions as warnings" mode by default - with an understanding that production code will be built with "warnings = errors" switch.
> If there isn't a return value, I don't.
What if there isn't a return value in the success case, but there is one in case of failure (i.e. the error)?
> Why do you need checked exceptions, as opposed to regular unchecked, typed exceptions?
You don't need, but you probably want them. Unchecked exceptions are invisible in the method's signature; to get a list of exceptions you need to handle, you'd have to dig through implementations of everything downstream of your method.
There's a trend across different languages to use algebraic data types (Result, Expected, etc.) to allow returning a valid result XOR an error, which by design make you deal with a possible error if you want to get the result. Exceptions are essentially the same thing, except with less boilerplate (in C++/Java-style language), but you need checked ones to actually force the programmer to deal with failure modes.