After all, you can always just choose not to use [checked exceptions] - just convert everything to runtime exceptions and your own code will be only impacted at the edges.
Forgive me if I'm being dense -- I haven't done much Java programming lately -- but what do mean by "convert everything to runtime exceptions"? Sure, you can define all your own exception classes as runtime exceptions. But checked exceptions seem unavoidable, as you can't (practically) avoid calling all the Java API methods that throw them.
> But checked exceptions seem unavoidable, as you can't (practically) avoid calling all the Java API methods that throw them.
Yes, that's what I mean by "at the edges". You can't avoid hitting the ones built into Java but you can stop them penetrating into your own code with a simple try / catch that wraps them with RuntimeException.
Comments
After all, you can always just choose not to use [checked exceptions] - just convert everything to runtime exceptions and your own code will be only impacted at the edges.
Forgive me if I'm being dense -- I haven't done much Java programming lately -- but what do mean by "convert everything to runtime exceptions"? Sure, you can define all your own exception classes as runtime exceptions. But checked exceptions seem unavoidable, as you can't (practically) avoid calling all the Java API methods that throw them.
Sorry, away for a bit and didn't see your reply.
> But checked exceptions seem unavoidable, as you can't (practically) avoid calling all the Java API methods that throw them.
Yes, that's what I mean by "at the edges". You can't avoid hitting the ones built into Java but you can stop them penetrating into your own code with a simple try / catch that wraps them with RuntimeException.