I argue against that. because the problem is not that error handling is hard, the problem is that it is mostly unnecessary. Basically if you would write a hello

I argue against that. because the problem is not that error handling is hard, the problem is that it is mostly unnecessary. Basically if you would write a hello world that writes directly to STDOUT you would need to handle IOException, guess what? it's basically useless to handle any kind of IOException in that case, because guess what? if your i/o device for output to display is broken you can only let your program crash. and that is the most common case how most exceptions are handled. and thats excalty where the k8s hype is about. fail fast, start from scratch. you can't handle a network error in your application, but you can basically kill everything that lost network access to your database and recreate it where database access is still possible. but you don't need to do that in your application, your infrastructure should handle these and thats why most checked exceptions in the java stdlib are basically stupid. 90% of the stuff reuses exceptions for ease of use but 90% of the stuff should be runtimeexception and 90% of them should split them up, between stuff that I COULD recover from and from stuff that I can't (i.e. SSLException should be split into validation of certificate exceptions and protocol violations!!! that mostly can't be handled without reconfiguring the JVM!!!! I mean there is a SSLProtocolException but it's basically useless since it reports a totally different thing..)