> However, in other languages, it may not be clear that your code is not handling a potential exception in a try catch code block, being completely opaque about

> However, in other languages, it may not be clear that your code is not handling a potential exception in a try catch code block, being completely opaque about handling your control flow. In other words, Go's error handling is an even less ergonomic way to do checked exceptions than Java's checked exceptions. I'm of the opinion that Java was right all along and they just didn't have the inference tools to make it ergonomic at the time, but I'm in a tiny minority there, and most of this article could have been swapped out as a defense of checked exceptions, while the rest is a subjective defense of the syntax. And then there are the things that checked exceptions give you that Go's errors don't: * Automatic stack traces. No need to decide that the error is "actionable to developers" and remember to load a library and wrap the error, errors have stack traces. I can't emphasize this enough. * You can opt out of the line-by-line exception handling by just declaring that your function can throw. The line-by-line manual handling is only valuable in cases where your functions are very long and might throw many errors (problematic for other reasons) or if you don't have stack traces and need to piece line numbers together by hand (see above). There are other flaws in Java's implementation, but it's been very frustrating to see how many of the new languages just reinvented Java's checked exceptions but worse instead of iterating on them.