Anders Hejlsbergism Why not introducing Checked Exceptions with Java in C #
This is one of the "http://www.artima.com series of short text. This series discusses his design C #'s ideas, focus on the C # to learn from Java, and read it, I will translate it into Chinese.
There are still two people involved in this article, one is the author of the Bruce Eckel, the Thinking Series (hereinafter referred to as BE); one is the editor of Bill Venners, "Inside JVM", www.artima.com's editor (BV).
BE: C # No Checked Exceptions. How did you decide not to introduce it into C #?
Ah: I think Checked Exceptions brings two questions: Scalability and VersionAbility. I know that you have also written about Checked Exceptions, you seem to agree with our point of view. [i]
BE: I used to feel that checked exception is a great idea.
Ah: Yes. Frankly, when they look, they are really great, and this idea is not wrong. I totally agree that Checked Exceptions is a good feature. It is just some specific implementation (for example, Java implementation) will bring problems. In Java, you just convert a type of problem into another, I don't think it (Java's way) makes my life simple, you just turn it into another problem.
Be: C # Other members in the Design Group have different opinions on this issue?
Ah: No. I think we have reached a wide variety of this problem. C # It is now basically not a statement on this issue. Once we discovered a better solution, (Believe me, we are still thinking about this question), we will publish it. I have always held this point: If you don't have an accurate statement on a problem, there is no perfect solution, then you don't know anything, not trying to build a big frame to solve it.
If you let the primary programmer write a calendar control, they often say this to themselves, "God, I decided to write a world's best calendar control, which will show a polymorphic behavior for different calendars. It will have Various fancy features. "They only have two months to complete this task, but use almost all times on the framework of the setup program, and take the time for two days to write the code about the calendar control. Then, they had to comfort themselves, I will do better in the next version.
Such a design method is wrong from the beginning. And I have continuously seen this phenomenon, one more, and then three. So I firmly believe that simple is beautiful. Unless you can solve a universal problem, don't turn a way to solve a specific problem into a universal framework, because you don't know how to design this framework.
BE: Extreme programming, "solve the problem with the simplest method."
Ah: Yes, Einstein does not say, "" Solving problems with the simplest way, but don't excessive simple ", I am worried about Checked Excetions Yes, it increases the burden of the programmer. [II] When you see a programmer with the Throws clause, their code has twisted, you will realize that Checked Excetion does not help them. This is actually the arbitrary API designer tells the user, what should you do, not the user decides what to do, this is the original place!
BV: You can further clarify the scarability and version control (SCALABILITY AND VERSIONABILITY)
Ah: Ok, let's take a look at the version, it is easier to understand. Suppose I wrote a FOO function, he threw three exceptions A, B, C. In the next version, I decided to add new features to Foo, and it will throw a new exception D. This is a change in trouble, because if the existing code is not modified, it will not be able to handle this new exception D. That is to say, the emergence of new anomalies in the new version will bring trouble to the programmer using it. This seems to be like a new method to add a new method. In fact, a public interface, it should not be changed once it is posted. If you want to add a new method, you should post a new interface. Abnormal situation is also similar: You either write a new method Foo2 to throw out A, B, C, D, 4 exceptions, or capture new exception d in your implementation, then convert it into a, b, c One.
BV: However, is this problem with the programming language without Checked Exceptions? If the new version of the FOO function throws out of the new exception, the user has to consider how to handle them? Is this not the same as the old code to bring trouble? [iii]
Ah: is not the case. Because in many cases, people don't care (these abnormalities). They don't intend to handle these anomalies. In the bottom of their message loop, this code only pops up a dialog, telling you, out of the exception, and then continue to run. (The actual situation is like this). Programmer will write Try Finally in all places to protect their code, which is that they can exit normally, but they don't care how to handle these exceptions.
The implementation in Java, the Throws statement does not force you to handle exceptions. If you don't deal with them, Java forced you must confirm what exceptions will be throwded out. You or capture these exceptions or put them in your throws clause. In order to avoid such trouble, people will do some stupid things. For example, they will add "throws Exception" after each function, which is completely violated by Checked Exceptions. When you see some of the lengthy code of people, you will mean that Checked Exceptions have not played any effect.
BV: So what you think is that people know that there will eventually have universal Catch blocks to handle exceptions, so they do not deal with them. (So you thinking the more commicitly handle Excers in Deference To a general catch clause further up the call stack?) AH: Interesting is what people think is important to handle them? This is actually not important. I personally think that a good program, try finally (or C #, similar to try finally) to the try catch proportion should be ten more than one.
BV: What is FINALLY?
Ah: In Finally, you can protect your code is not affected by an abnormal, but you don't deal with exception. Exceptional code you can put in other places. All event-driven programs, like any Modern Image User Program (MODERN UI), you will put an exception handling code in your message loop, which only handles them when you go to this block. But you must confirm that all resources have been released, do all the necessary cleanup work (in the Finally block) so that you can protect yourself in a consistent, correct state. [iv] You will not want a program to have 100 different places to handle exceptions, and pop up dialog box. What do you want to change the pop-up dialog? (Then you will modify 100), this is terrible. Therefore, the code to deal with exception should be concentrated (The Exception Handling Should Be Centralized). You only need to protect yourself before being processed.
BV: What is the scalability issue brought by Checked Exceptions (SCALABILITY)?
AH: Scalability and VersionAbility are some associated. In a small program, Checked Exceptions are very attractive. In a small program, you can see you really capture FileNotFoundException, which makes people exciting!
When you only call an API, it is true. But when you start building a large system consisting of 4,5 subsystems, it will appear. Each subsystem will throw out four to ten exceptions. These to throw out an exception is like a ladder, let you climb getting higher and higher, do you start thinking? Eventually you may hit a piece of code to throw a 40 exception. And when you combine this large system with another system, you will even throw out 80 exceptions, which is too terrible.
In general, when Checked Exceptions become uncontrollable, people will take some extreme measures to evade it. So you will see they simply write "throws exception". I can't even tell you, how many times I saw people writing this:
Try {
...}
Catch () {}
Catch () {}
...
They will be comfortable to say, wait for me to make a time to make up the Catch code, but actually they will not. In this case, Checked Exceptions actually reduces the quality of the code.
So, when all of these situations are considered, I decided to make more thinking to decide whether some form of Checked Excetions join C #. Of course, you can know what kind of exception will be thrown in advance, and some kinds of tools are undoubtedly valuable. I don't think we can set a strict and effective rule to let the compiler do this. Of course we can do a lot of analysis work to detect suspicious code. Include what unpaged exceptions have, and tells these potential dangers user. [i] http://www.mindview.net/etc/discuss/checkedexceptions
[II] This problem, the author also asked him when James Gosling visited him, may be due to the atmosphere of the venue, Gosling is just a hurried answer, he doesn't care whether it adds to the programmer, he cares It is the correctness of the program. Interestingly, James Gosling also published his for Checked Exceptions at www.artima.com: http://www.artima.com/intv/solid.html
[III] In "The Design and Evolution Of C ", Bjarne Stroustrup also mentioned that the same is based on this problem, C does not have "Static Checking" but "Run Time Checking". And Stroustrup recommends that for the throwing out of the new exception D, it can be inherited from the existing exception, which does not affect the existing code, and the new code can also handle it. (This is the conclusion made in Stroustrup in 1990!)
[iv] This actually Stroustrup repeatedly emphasizes RAII. Because there is no destructive function, it has to be simulated with FINALLY. (How much characteristics have C never understand! How many people use C as c with class, sigh!)
