That guideline ends up less great than it sounds, in practice, since the kind of error a client can recover from is very client-sensitive. A general-use library

That guideline ends up less great than it sounds, in practice, since the kind of error a client can recover from is very client-sensitive. A general-use library, like Java's, needs to throw checked exceptions for anything that /any/ caller could reasonably catch. If you're writing, say, a file converter, then there's nothing you can reasonably do about an IOException. But plenty of other programs can show an error dialog and keep moving. There's usually going to be some sort of exception that's completely out of scope for you. As unfortunate as that is though, I don't really think it's something that can be done better. Ultimately errors are breaks in a function's abstraction. There's nothing that a readFile() function can do about a missing file, because it doesn't know how that file was selected or what you're going to use it for. The only way around the error would be absurdly coarse abstractions like readUserSelectedFileInGuiProgram() and readCriticalFilePackedWithProgram(). Better syntax can reduce the boilerplate - algebraic types plus match expressions are certainly an improvement. But the guidelines for when you should return one end up the same as the guidelines for a checked exception, since they're expressions of the same idea.