Article Discussion
The Trouble with Checked Exceptions
Summary: Anders Hejlsberg, the lead C# architect, talks with Bruce Eckel and Bill Venners about versionability and scalability issues with checked exceptions.
46 posts on 4 pages.      
« Previous 1 2 3 4 Next »
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: May 6, 2013 11:03 AM by Gregg
Gregg
Posts: 28 / Nickname: greggwon / Registered: April 6, 2003 1:36 PM
Re: The Trouble with Checked Exceptions
May 6, 2013 11:03 AM      
The basic idea of Checked Exceptions, is that there are some things, in software system, which happen because of outside stimuli. I/O subsystems, for example can cause exceptional problems when networks fail, disks crash and many other things in related ways. In the case of I/O, you have a "context" related to that I/O, which controls how you react to the problem. Checked Exceptions are a good thing to announce to the software systems, that something has occurred, which will keep the software from accomplishing the task it has initiated, and the software CAN take action which can correct the condition.

RuntimeExceptions in Java are about "system" or "software" errors, which will likely keep the software from working correctly. ArrayIndexOutOfBounds exceptions as well as the Error subclasses of Throwable, represent many common issues.

The fact that C# has no checked exceptions, for me, is a cop-out on the problem. It means that they didn't spend time to really talk to experienced developers creating large software systems that run in a server environment, to understand how important it is for some software systems to "never-fail".

Microsoft, historically, has lacked this expertise, and even today, some 10-years since this interview, the situation has not really changed. C# is still missing all kinds of important features for software stability and uptime, which Java continues to provide great benefits from having.
46 posts on 4 pages.
« Previous 1 2 3 4 Next »