Why wasn't the Java "throws" clause (in method declaration) included in C#?

Question

Why wasn't the Java "throws" clause (in method declaration) included in C#?

Answer 1

Anders Hejlsberg (the lead C# architect) explains it in this interview:

http://www.artima.com/intv/handcuffs.html

Answer 2

(In addition to Patrik's somewhat-definitive answer.)

Checked exceptions in Java are a very controversial issue. I used to love them, and missed them a lot when writing C#. It felt like I was driving without a seatbelt. Now, they annoy me... because while they sound like a good idea in theory, they've definitely caused me a lot of grief but without providing much tangible benefit. I can't remember ever encountering a bug in C# code which checked exceptions would have saved me from. That's not to say it can't happen, but it hasn't happened to me.

The annoying thing is that in some ways it still feels like C# is too lax - but that Java's approach isn't quite the right one. It's like there's a better solution waiting to be discovered, and Java's attempt was a good experiment, but it didn't quite work.

Answer 3

The main reason is that C# designers decided not to use "checked exceptions". This means that the developer doesn't have to surround an exception throwing clause inside a try-catch block. It was considered that this is only helpful for small scale applications and doesn't have a real benefit for bigger projects. Additionally checked exceptions were actually misused by the developers, who constantly use empty catch blocks. Since there are no checked exceptions, there is no reason for a method to declare, which exceptions could be thrown.

The use or not of "checked exceptions" is a controversial topic, but most seem to agree that there is no need for them. Spring, which is a prominent framework in Java, turns checked exceptions into runtime ones.

Answer 4

I think checked exceptions, as a language feature, exposes some of the cultural differences between Microsoft and Sun.

For the most part, Microsoft is a client company. Most of the software they make, and what their development stack is targeted at, is client software.

Yes, yes, I know that Microsoft makes server software. However, Office and Windows are WAY bigger in terms of revenue than Windows Server and Exchange are.

I think it's fair to say that most software written in .NET, (and even more so with VB 6) is client software. Sure, a big chunk of it is Web Software, that runs on a Web Server, but most of it is really ... "clienty type web apps". I'd say most web apps are more like "Word" then they are like Exchange.

And yes, I know there are WCF and SOAP services and things like that, but those are usually just "middle ware" for "clienty" type stuff.

Sun, on the other hand, is primarily a server company. Their software isn't exactly the greatest when it comes to user interface (this isn't a slight on Unix... just Solaris.. Mac OS X is based on unix and it has a phenomenal user interface, the difference between the two is that Sun really doesn't care as much about UI as Apple does ). They even sell THIN CLIENTS, which try to push everything onto the server.

So... in any case... Microsoft is mainly a client company, and Sun is mainly a server company.

When you write server software, reliability is a big thing. It's huge. If an email server crashes, people don't get email, and business grinds to a halt. So, making sure that the server can intelligently handle most errors that can happen is a big part of selling an email server.

With client software. reliability IS important, but no where near AS important as it is with server software. As long as most main line scenarios work, people are happy. In many cases, crazy edge scenarios can just be ignored, or handled generically.

One key to being super reliable is making sure that you handle all the possible edge cases that can occur. What happens if we can't open the database file because it's locked by another process, or we don't have permission to read it? What if we run out of memory, or disk space? What happens if the power goes out while running this procedure?

With really high reliability requirements, having checked exceptions CAN be helpful. If there is a scenario you didn't anticipate, and it's important to your business that you anticipate everything, then having the compiler tell you ... "hey you didn't handle the RocketFuelExhaustedException" would be helpful.

So, I think checked exceptions stem from Sun's point of view as a server vendor.

To Microsoft, as a client company selling developer tools to client software developers, checked exceptions are of course horribly irritating things that just get in the way of real work getting done.

That's my $0.02 anyways...

Answer 5

Exceptions are apparently 'exceptional' events. In .net's paradigms, exceptions should never occur (that's why you have methods like TryParse, ...), so it makes little sense to be forced to handle events that shouldn't occur anyways.