I have worked on 2 programming languages in my career. Java and C#. I have sort of worked 50:50 on both. Sometimes while I code, I miss some features of the either language. I ‘ll try to take one feature at a time. Today’s feature is Exception Handling. To be precise Java has checked exceptions, C# doesn’t. The C# camp says, “Well, we are all mature developers, I don’t need the compiler to tell me that something bad is going to happen. Besides, it encourages people to write exception handling code all over the place and it clutters the code base” Well guys, not all developers are rock stars and unexpected things happen more often than you think they do. In today’s service oriented systems, a lot of components talk over the wire and if one service decides to throw up, then well that’s something that most developers don’t think will ever happen. Seriously guys, do we think of such stuff when we write code ?? All we think of is cool object orientation, design patterns and what not. But what we to have remember is that, software spends a much, much larger time in production than in development. This means that the likelihood of bad stuff happening is that much more. If people spend a little time in production support, they will appreciate the ‘defensive’ way of checked exceptions that java offers. When you are using an API which tells you that, there could be a possible TimeOutException, you will think again and add a unit test case for that scenario. Faster feedback and less chances of prod support taking days to finally figure out that your code couldn’t handle a service breakdown more gracefully. A compiler error is faster feedback than a runtime exception (especially if the runtime is production). For the brave hearts, Java also offers the C# way of unchecked exceptions. Just extend your exception from RuntimeException. I know most people get reminded of an EJB interface when they see a throws (100 exceptions). But just think about it, was there a reason why there was a ‘throws’.