Lately, I’ve been working on a project in Microsoft Visual C#. The language itself closely resembles Java (especially in certain parts of the class library exposed by Microsoft .NET), but its heritage is more C++ than Java. Inheritance is via the same construct/syntax as C++, and both interfaces and classes are inherited this way, unlike in Java with its extends and implements keywords.
However, one thing that nags me about C# (and has caused me to rethink things in Java) is the fact that all exceptions are unchecked. (Offhand, someone on the web mentioned this while comparing Java and C#; I can’t remember the URL though). This means that calling a method that may throw an exception (for example, ADO.NET stuff may throw SqlException) without catching the exception anywhere means that somewhere down the line, your application/system will die a violent death when some exception does occur. Which means that you have no idea where exactly to code your try..catch blocks, and if ever, end up catching Exception, just in case. Ugly.
This also means that you have to explicitly add documentation to your code to mention that you are throwing certain exceptions. (Reading through the code will not help, unless you intend to read several levels of files/classes deep).
And, grudgingly, I’ll admit that checked exceptions are elegant and needed. Unchecked exceptions do remove some of the bother of having to write try..catch blocks, but they also mean that exceptions go undocumented. Certain exceptions are worth being unchecked, but not all.
Of course, since I am not yet completely a C# developer, I may have missed out some of the more obscure corners of the language.
(On a somewhat unrelated note, I found myself typing C$ instead of C# while writing this post. Interesting… hehehehe)
Previously: Zealotry in F/OSS