Advertisement

Exception versus Wrong Result

Bill Venners: Bertrand Meyer, in his Object-Oriented Software Construction book, talks about his philosophy of contract. If I'm a method and I say in my documentation -- or my preconditions, in the case of Eiffel -- that you have to pass me a positive int, then if you pass me a negative number, Meyer says it's okay if I give you a wrong answer back. Because you have broken the contract. What he wanted to avoid is you checking to make sure you're passing a positive number and me checking to make sure you're passing a positive number.

My take on Java's philosophy on that, however, is no, I should check for a negative value and throw you back an exception, so it's predictable what I do if you break the contract.

James Gosling: Yes, and actually what I think the correct answer is--and this is what I was trying to do -- was to make the contract evaluatable as much as possible at compile time. So that, where possible, you could actually say, "the value you're passing me is going to be negative or could be negative. Bad, bad, bad." Because when a contract violation is indicated by passing an exception, you don't actually see that until the code is actually running, which gives you this testing problem.

Whenever you're testing something, you have to make sure you actually exercise all these bits and pieces. And the world is filled with hunks of code that were written to handle some exceptional situation, and they have never actually been tested.

It may be that if you have a parameter check, "Is this a negative number?" it almost never actually happens that it's negative. It's the Ariane 5 problem. Remember the Ariane 5 failure?

Bill Venners: You have a link to that off your webpage.

James Gosling: Yeah. It like blew up. And that was because they had taken this one piece of software with a parameter in it that had to do with the trajectory. It was built for the Ariane 4, but the Ariane 5 had bigger engines, and the rocket was getting into the flat part of its trajectory while it was still accelerating. So numbers were coming out of range.

I believe it is completely beyond the sate of the art to try to do that kind of analysis statically, that particular one, but there are all kind of analyses that you could actually do. You don't declare failure if you can't do everything statically, but every thing that you can push into the static analysis phase of the system to get earlier and earlier is yet another source of reliability to the system.

Bill Venners: Interesting. Given what we have, then -- we have Java as it is -- what should we do to prevent our rockets from exploding? Should I, at the beginning of my method, just make sure you pass me good data and throw an exception? In either case we have a problem, especially if this is controlling a rocket, whether I give you a wrong result or throw an exception. Or let me ask it this way: Bertrand Meyer says an exception indicates a broken contract. What do you think of that?

James Gosling: I guess in the Java world, exceptions can mean lots of different things. Some of them are broken contracts. In the world of Throwable things that can be tossed around by the exception mechanism, there are two classes. There are the ones for which the checking algebra happens. I think those are predominantly the contract violations. But, for example, in the file I/O system, when you go to open a file and the file isn't there, you get an IOException. In that case, it seems to me that the exception is a part of the contract and you can actually handle it.

There are things that can go wrong for which it's actually reasonable to expect the application to be able to handle. And even outside of that, one of the things that people do a lot in Java if they are building a command dispatch loop, and it's invoking things that are plugged in, is wrap that call with a try catch Throwable. That will catch all kinds of errors, even the ones that are contract violations. That can be a really great way to increase the reliability of the system, because it gives you a way of saying, "Okay, this piece of the system just died horribly because it had a contract violation, but damn it, I've got to carry on."

So, in the Ariane 5 case, the problem wasn't actually that they had this range problem, because the range problem was only in this diagnostic system. The problem was that when the out of range value happened (and the out of range value happened on all of the computers, because they all had the same code) then they dumped ASCII -- I don't know if it was a stack trace or what -- out on this main serial line. And that serial line happened to go to the gimbals that controlled the motors. And so, instead of getting pointing angles for the engines, it was getting a stack trace and the gimbals went erh! erh! The engine went erh! And the thing just tore itself apart.

Bill Venners: That makes sense. It's a good justification for throwing an exception, because then I can catch Throwable. If you just give me the wrong answer, I'm not going to know.

James Gosling: Right. And in systems that have to be long lived and reliable, they have to have a comprehensive strategy for dealing with failure, because failure always happens. There will always be bugs, there will always be pieces of equipment that get smacked. There will always be alpha particles that hit busses. Things go weird and the average answer, which is to just roll over and die, is not a useful one. And particularly as you get into the systems like flight avionics, you just don't get to crash.

Bill Venners: You don't get to crash.

James Gosling: From the software's point of view, you have to keep on going, you have to do something sensible. You can't just say, "Oops, no, I'm not going to work anymore."