The problem with checked exceptions is that your code trends towards having every method marked as 'throws Exception' (or whatever your application's top level

The problem with checked exceptions is that your code trends towards having every method marked as 'throws Exception' (or whatever your application's top level exception is). Any time a low level method changes to throw a new exception, every method that calls it has to update their exception spec... or they need to have their catch clauses updated to catch the additional exception and either deal with it - unlikely - or wrap it and rethrow it as one of their other expected exceptions.... or they're already catching Exception, which is also bad. At my last job, very few methods in the application ended up throwing a specific list of exceptions, except the most leaf-ward modules. Anything anywhere near the application logic just threw our top level generic exception, because there was too much below them that could throw a variety of exceptions, and there generally was nothing the middle-tier code could do about it if they failed. It's really not that easy to ignore errors in Go in practice... and you might as well worry that a library correctly handles the result of string.Split() incorrectly. Either one is a bug. Hopefully your tests would find either one, and there are tools to detect errors you didn't handle.