> If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception

> If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception. Trying to make those decisions as a library author is a sort of combination of the tail wagging the dog and self-fulfilling prophecies. Depending on the client's ethos and operating parameters, they may or may not reasonably want to try to recover from anything. Java's designers decided that failing to reserve memory for a new heap allocation isn't something that people might want to recover from, and so it really is impractical to do so - for lack of documentation as much as for any technical reason. On the other hand, Zig decided that developers should be able to recover from it, and so it's really not such a big deal for Zig developers. Personal example: I tend to be a "let it crash" person, so I generally write code that throws exceptions that really are hard to handle. Not because of any fundamental reason, just because that attitude leads me to be a bit more loosey goosey about organizing and documenting the exceptions that I throw. I get away with it because it's all internal projects. If I were writing an open source library meant for public consumption, I'd probably try to be more disciplined, so that users could choose their own moral paradigm.