3 ms·

I've never had a Java IDE insert something like that? But either way, you have to go out of your way to do that, which is sort of my point. The one place wher

by suresk 5y ago

I've never had a Java IDE insert something like that? But either way, you have to go out of your way to do that, which is sort of my point. The one place where you do see dumb boilerplate and chances to screw up is in dealing with checked exceptions, which have been controversial since the very beginning. I think they are one of those things that seem like a great idea in theory, but end up not working out so well in practice, but (like people who appreciate Go's error handling model) there are people who disagree.

m45t3r 5y ago
Exactly. It is kinda obvious that someone is doing something wrong with the code when they're doing a generic catch (sometimes it is fine, but this will at least raise some eyebrows). However it is very easy to do the wrong thing using Golang. Just one random library doing `fmt.Errorf` without the `%w` verb is sufficient to lost all information from there on. I would much prefer some kinda of annotation that does the correct thing by default (wrapping the error) instead of the "every error should be explicitly" approach of Golang.
ithkuil 5y ago
> I've never had a Java IDE insert something like that? yeah this indeed happens with checked exception and careless developers just wanting to get stuff to compile (we'll handle that property later) and the IDE helpfully providing the boilerplate that resolves the compilation error (and assumes you'll fill the body)
anonymoushn 5y ago
The above code is probably caused by checked exceptions. In particular, the user wants to implement some interface or override some method, but that method wasn't declared to throw a particular type of exception because the people who wrote it hate extensibility and never want their software to be used in a way they didn't anticipate, so the new implementation can't throw it either.

3 ms·

I've never had a Java IDE insert something like that? But either way, you have to go out of your way to do that, which is sort of my point. The one place wher

by suresk 5y ago

m45t3r 5y ago
Exactly. It is kinda obvious that someone is doing something wrong with the code when they're doing a generic catch (sometimes it is fine, but this will at least raise some eyebrows). However it is very easy to do the wrong thing using Golang. Just one random library doing `fmt.Errorf` without the `%w` verb is sufficient to lost all information from there on. I would much prefer some kinda of annotation that does the correct thing by default (wrapping the error) instead of the "every error should be explicitly" approach of Golang.
ithkuil 5y ago
> I've never had a Java IDE insert something like that? yeah this indeed happens with checked exception and careless developers just wanting to get stuff to compile (we'll handle that property later) and the IDE helpfully providing the boilerplate that resolves the compilation error (and assumes you'll fill the body)
anonymoushn 5y ago
The above code is probably caused by checked exceptions. In particular, the user wants to implement some interface or override some method, but that method wasn't declared to throw a particular type of exception because the people who wrote it hate extensibility and never want their software to be used in a way they didn't anticipate, so the new implementation can't throw it either.