Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

exceptions: Why no 'catch or specify'?

Java has the requirement that a method either catch or specifiy via the keyword "throws" all the checked exceptions that it might throw.

Why did the .Net folks chose not to have a "throws" keyword? 

TomW
Wednesday, November 27, 2002

http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820&I=-3

Duncan Smart
Wednesday, November 27, 2002

There's a good discussion of this in an MSDN chat (search for "throws"):

http://msdn.microsoft.com/chats/VSTUDIO/vstudio_081502.asp

The short answer is that there were technical reasons to do with versioning, but it was also a stylistic choice.

The 'throws' keyword helps quality at the expense of programmer productivity. Religiously maintaining the list of exceptions all the way up your call tree is a such a pain that developers often don't bother - they just blindly add throws clauses all over the place until their code compiles (who hasn't done that?). Also java compilers don't whinge about spurious throws statements so it's easy for them to get out of date.

Ross McNab
Wednesday, November 27, 2002

I am kind of not convinced.

I am always careful with exceptions, throwing ones I think that the caller ought to be able to recover from.  I think it helps my productivity, *especially* on large projects.

.what?
Thursday, November 28, 2002

I have to agree that forcing programmers to think about their exceptions helps a big project over the long term. I also sometimes wonder if 'productivity' is used in place of 'laziness'.
- Just my opinion :)

~ajt
Thursday, November 28, 2002

I think that the "throws" clause helps the same way as the strict typing - until you force an object to cast to another type - it encounters as an error. I think that throws is the signature / type of the function. It allows finding errors on compilation time and not after long debugging hours trying to find which line of the code causes specific exception that was caught in “main” procedure.
  I’m the biggest fan of treating all the warnings as an error – the code is not complete until all the uncertainty in it is resolved. The “throw” clause narrows the uncertainty in the code.

Igor Moochnick
Monday, December 02, 2002

"[throws] allows finding errors on compilation time and not after long debugging hours trying to find which line of the code causes specific exception that was caught in “main” procedure"

But I simply don't find this a problem due to the way you can nest exceptions:
  throw new MyException("blah", innerException);
and being able to:
  Console.WriteLine( myException.StackTrace );

Duncan Smart
Monday, December 02, 2002

Even more interesting is that some in the java camp have been questioning the use of checked exceptions themselves...

http://www.mindview.net/Etc/Discussions/CheckedExceptions

http://www.milk.com/java-rants/rant01-interrupted.html

(BTW, Bruce Eckel's Thinking in Java book is highly recommended if you are any bit interested in java. Pdf, word, html versions are available for free from his site)

AEB
Tuesday, December 03, 2002

*  Recent Topics

*  Fog Creek Home