eiffelroom - Exception handling - Comments

Retrying

maverick — Sat, 27 Sep 2008 08:21:38 -0700

And when you speak of retrying, it is mostly done by the software, right? And in this case, without exceptions so most of what you do is calling an attempt procedure which includes failure in its contract, right?

Also, what is the REST approach?

Spec#

maverick — Fri, 26 Sep 2008 12:53:05 -0700

Thanks for the link I did not know of the resemblance. My previous exposure to the treatment of exceptions in Spec# gave me the impression that they are expending a great lot of efforts to be able to prove correctness in the presence of exceptions.

Several designs I saw in systems written in C# made a great impression on me: exception handling seemed to be used as a usual control structure. I tried to fix it up but it seemed to be caused by the structure of the .NET framework. If this kind of design is indeed a good characterization of the .NET style, I would not be surprised that it would justify the effort that the Spec# team dedicated to handling exceptions.

Anyhow, this opinion is probably what prompted me to wonder about the amount of efforts that is worth spending for guaranteeing exception safety. I'm hoping that it is very little since its usage obfuscates the control flow.

Simon

The architecture in this

berend — Thu, 25 Sep 2008 18:54:17 -0700

The architecture in this case is specifically the architure on how you handle failure. First some individual examples:

For example web sites are resilient against failure. If the server cannot handle the load, users can just retry later.

Same for updates to the db: if you do that in a transaction, even if the program fails, that will not change the db.

Communication between programs can be handled likewise: you can use message queues to make sure messages don't get lost.

The collection of all such techniques is the architecture in this case. As I'm a big fan of the REST approach, if you built web applications you get most of this for free. It's built-in. You do something, if you don't get a response, you try again. So the architecture is not the software, but how the software behaves in case of an error.

A simple example of architecture that handles software faults is a daemon wrapper: the wrapper starts the daemon, if the daemon fails (out of memory), the wrapper starts it again.

On strategies for memory or disk: I think both failure cases are similar, than you can solve subcases in some situations doesn't mean you can solve most of the problems. I.e. in both cases you could trade memory for disk and vice versa, but that solves only minor cases.

Computing takes place on a dynamic platform with no guarantees and it can run out of resources. Handling that gracefully is architecture.

Spec#

peter_gummer — Thu, 25 Sep 2008 18:32:52 -0700

Your ideas remind me, Simon, of something I read a few years ago at http://research.microsoft.com/SpecSharp/ about checked exceptions in Spec# (Microsoft's research language that retrofits contracts onto C#). I think the exact link may have been http://research.microsoft.com/SpecSharp/papers/krml135.pdf .

(The Spec# team's research into not-null types influenced the addition of Void-safety to Eiffel, if I remember rightly.)

Berend: I think this is an

maverick — Thu, 25 Sep 2008 17:27:33 -0700

Berend: I think this is an architectural issue, not a language issue. I wrote programs that can safely crash if they run out of memory.

Here, you are referring to a software architecture, right?

Berend: I wrote programs that can safely crash if they run out of memory.

I would very much like to hear more about that. Not that I am doubtful of such a deed but I held the belief that memory management was the only issue that required exception handling even if it's not related to the interface with an external system.

Berend: You can't handle out of memory in Eiffel just as you can't handle out of CPU or out of disk.

I'm a bit puzzled by this sentence. Do you mean that the strategy for recovering from a failed memory allocation is different of that for recovering for lack of disk space? Or do you mean that they are both equally impossible things or that just one of them is?

Berend: So I rather have a program that is written for an idea machine, and let the architecture handle the real world problems.

I agree that it is better to design a program while abstracting from the constraint of the machine that will execute it. However, I am not clear as to what kind of distinction you make between the program and the architecture (if it's a software architecture). Do you identify as the program the collection of executable statements of your system whereas the architecture would be the class hierarchy and their interfaces?

Simon

Simon: we still need to

berend — Thu, 25 Sep 2008 16:14:24 -0700

Simon: we still need to report memory insufficiency.

I think this is an architectural issue, not a language issue. I wrote programs that can safely crash if they run out of memory. Things just get retried (either by users, or by programs). You can't handle out of memory in Eiffel just as you can't handle out of CPU or out of disk.

You can handle out of disk by buffering and write to disk once more disk is available, but of course only a subclass of problems can be handled by this approach. So I rather have a program that is written for an idea machine, and let the architecture handle the real world problems.

But given the case we

maverick — Thu, 25 Sep 2008 15:20:43 -0700

But given the case we identified, it seems unlikely that we will see a computer with infinite memory be sold or that we will run out of system written in C++ or .NET to interface with. However, I am not abandoning my (somewhat weak) idealism that we will have Eiffel systems whose total correctness is proven.

Berend: A bit like Java does? I.e. if one of the routines can thrown an exception, you have to specify how you handle it or so? Very cumbersome.

Yes I would choose something like what Java has. It is certain that it is cumbersome for Java but, then again, Java does not have Design by Contract. By my experience, it seems that most exception in Java are used to report precondition violations. If we remove the exceptions declared for the sake of reporting such violations, it seems very bearable to force the declaration of exceptions where we interface with non-Eiffel systems since they are a minority.

As such, the exception mechanism could almost be classified like external features are. The only thing keeping me from doing this classification is the fact that, even with the proof of total correctness, we still need to report memory insufficiency.

Simon

Simon: Would you assume that

berend — Thu, 25 Sep 2008 14:52:33 -0700

Simon: Would you assume that it is an implicit convention to avoid exceptions like the plague?

Exactly.

Simon: Also, don't you think that making mandatory the declaration of exceptions in Eiffel would solve the problem you refer to in your question?

A bit like Java does? I.e. if one of the routines can thrown an exception, you have to specify how you handle it or so? Very cumbersome. Given that an exception in Eiffel is impossible for a correct program on an ideal machine (enough memory etc.) I think we don't need that. Would help little if at all, and make every feature you write so much harder.

Thank you very much. This

maverick — Thu, 25 Sep 2008 14:07:56 -0700

Thank you very much. This provides a piece of information I very interested in: the scarce use of exceptions in Eiffel. Would you assume that it is an implicit convention to avoid exceptions like the plague?

Also, don't you think that making mandatory the declaration of exceptions in Eiffel would solve the problem you refer to in your question?

"The biggest problem is: what is the class invariant if one of its routines throw an exception?"

Whenever you call a feature which may raise an exception you have to do something about it. It seems like a good indication that you have to take care of your class invariant in that routine.

I might add: we all agree that introducing a construct as a tool for lazy programming is something to avoid. Therefore, it would seem that applying the systematic declaration of exception would get rid of lazy designs. Good, isn't it?

Simon

Exceptions are bad

berend — Thu, 25 Sep 2008 13:41:19 -0700

Exceptions are bad in Eiffel. The biggest problem is: what is the class invariant if one of its routines throw an exception? There's only one case to throw an exception and that is to bubble up an error to the layer that stores the error for later analysis, before dying.

There might be some minor cases, as pointed out, you might or could rescue from C/C++ exceptions, but Eiffel exceptions are contract violations, and hardly any Eiffel program can recover from that.

Exceptions are useful when you want to take shortcuts: for example eposix, and other libararies such as ECLI do to, optionally throw exceptions on error. So you can be lazy and know your program doesn't continue in case weird things happen. And if you want to build full-blown error handling, you can do to by disabling such.

I agree that assertion

maverick — Thu, 25 Sep 2008 13:11:09 -0700

I agree that assertion violations and lack of memory must cause unintentional exception but, aside from running test suites there are still two different and important use for intentional exceptions. Interfacing with another software system (C, .NET, Java, etc) and interfacing with a hardware system (e.g. a network interface).

In Java, you have both intensional and unintentional exception. The NullPointerException is an example of unintentional exception. For the rest, we have a mix of contract violation exception and of actual failures. It happens that mixing the two makes the interface of Java classes and routines full of noise for which we should be (and probably are) glad that it is not the case in Eiffel. Getting rid of those noisy cases may make it both usable and useful to have this kind of documentation.

It is acceptable that, in order to keep the development of Eiffel compiler management and well organized, we may reject the integration of very good and helpful feature.

So even under the assumption that the explicit declaration of intentional exceptions is not a priority for any compiler developer, I find it interesting to study its value in the context of the Eiffel method.

The heuristic I use for evaluating the usefulness of this kind of feature is checking at the impact it would have on the ability to prove (say) local correctness, which, as I see it, is a total correctness where we assume the call graph is acyclic.

It may appear as a totally irrelevant heuristic for people whose method is based on testing but I maintain that is very useful. Indeed, if it is impossible (or inefficient) to reason formally about a particular construct, I think it is totally hopeless to try and reason informally about it.

In this case, I think using explicit intensional exception would greatly increase the productivity of such development because the mere fact of looking up at a classes interface would allow a programmer to know if he has to guard his code against an intensional exception.

Finally, thank you for giving me of the terminology of intensional and unintentional, I was not aware that it existed. However, I am wondering if a more symmetric one exists like intensional and silent or intensional and discrete to name but two examples.

Simon

Declaring exceptions

schoelle — Thu, 25 Sep 2008 09:24:16 -0700

This is a great description and analysis of exceptions. In my personal opinion, there are only two kinds of exceptions: intenional and unintentional.

Intentional exceptions are exceptions that you expect to be raise. If the exception is raised, you can directly point to the source of the problems. The rescue clause then has a predefined mechanism to deal with these exceptions.

Java uses intentional exceptions as a regular way of flow control within the program, but that is normally rejected by the Eiffel community.

The main reason to have intentional exceptions in Eiffel systems is for executing code that you know might fail, but you have no way of testing before the execution. Examples are interfacing C routines or running test suites.

Declaring intentional exceptions in the header of a routine (Java style) has its advantages. But as there are just few applications for intentional exceptions, I am not sure that the increase in complexity of the language is justified.

The main application of exceptions in Eiffel are unintential exceptions. Eiffel, with Design by Contracts and its other assertion mechanisms, has an extensive system for a program to detect at run-time that something "went wrong" (in Eiffel this is called "a failure"), as the overall consistency of the system was violated.

Unintential exceptions cannot be declared and completely rescued: if you know that you can raise this exception, you can as well just go ahead and fix the bug. You also cannot completely recover such an exceptions as you do not know what went wrong.

The rescue clause normally does not have the job of recovering from an unintential exception, but instead to implement robustness (with degraded functionallity).