[tieTYT]

I like checked exceptions in certain situations. I generally dislike the checked ones that come with Java ^1, but it can be very useful to create your own. I had a situation where I was interacting with an API that would sometimes fail over things I could not control. But, the code responsible for interfacing with the API didn't have the context for handling those errors.

Initially I threw a Runtime (ie: non compile time) exception. After going to production I realized that these were bubbling up to the UI and giving the user very intimidating error messages. So I changed the exception to a Compile time exception and then the compiler caught every place I let the error slip through to the UI. In my opinion it saved me a lot of time and made my code easier to maintain.

1: EG: Who is Java to say that this IOException should be handled in code? Perhaps this IOException should not happen and requires a developer's intervention.

[brianpgordon]

InterruptedException is the worst. I know that I'm not calling Thread.interrupt() so why do I need to handle that case? It's already hard enough to reason about multithreaded code without worrying about future-proofing it for some case where it's somehow convenient for another developer to use Thread.interrupt().

[mercurial]

I used to think checked exceptions were mostly an annoyance. Then one day, when working with a library doing I/O in Haskell, I realized that I couldn't pattern-match on whatever exceptions it may throw because I didn't know what they were and the type system was no help. Since then, I learned to live with the verbosity.