Of course. With unchecked exceptions, it's impossible to statically check that this is the case, so for system programming they are not an appropriate error handling mechanism.

None of system programming can be statically checked, since it's mostly about I/O with weak memory models.

Caveat: we may be using different definitions of "system programming". The one I'm using is code that is fairly close to the system, i.e. will call into libc or into the kernel/libSystem/etc. as well as calling more-or-less directly into a bunch of system-specific .so/.dylib/.dll.

In my experience as a system developer, you need to invest some time into understanding the invariants expected/promised by the libraries you're calling, but many of them map nicely to static types. Of course, if you're implementing e.g. a IPC or RPC layer, you need to deserialize (and validate along the way) your inputs, but there are very few systems that do not need to do that regardless.

Code that uses libc is just normal code.

I don't disagree :)

> With unchecked exceptions, it's impossible to statically check that this is the case

Aren't checked exceptions just a hint to the programmer?

Also I don't see why static analyzers shouldn't be able to map out which functions throw which exceptions without having hints in the language itself, the information is in the code.

Lastly if the goal is as simple as catch all exceptions, can't you just enforce a catch all on the top level?