Talk:Ada Programming/Error handling

DbC
With all due respect, the treatment of Design by Contract is sloppy, to put in mildly, and somewhat bragging about Ada's type system. In fact, DbC is formally specified, see ECMA 367, 8.9. It is integrated into Eiffel's vocabulary, and checked both at runtime and at compile time, covering a lot more than Ada can now hope to achieve. (See for example the discussion of introducing pragma Precondition and pragma Postcondition in the AI database.)

Ada's expressiveness is not the same in this regard, so I think it isn't the best thing to establish and instrumentalize a fuzzy notion of precisely defined concepts of DbC. (Except perhaps for anti-Ada trolls.) It is appropriate to make a reference to DbC, though.

It is true that the SPARK language and Eiffel have some common "mechanics". You can specify pre/post-conditions, you can have check-correctness and loop correctness, at the Ada subprogram/Eiffel feature level, for example. Of course, exception correctness is not needed in SPARK, but it would be needed in Ada, were DbC introduced to Ada.

But where is the class consistency in Ada, provided by class invariants in Eiffel? Initialising an object of a tagged type must establish the class invariant INVC, every call of a primitive operation must then reestablish INVC. This is of course integrated with the pre/postconditions of subprograms. How do you express this in the Ada language. I think it is fair to say that class correctness/package correctness is not available in Ada. What about package-scope operations not bound to the tagged type, yet affecting object components?

Inheritance in DbC means that contracts are inherited in a similarly consistent way that must follow formal rules. Failing that, the compiler will not accept the program text. (Roughly, oring of the preconditions, and anding of the postconditions, etc). I think talking about the pros of Ada's type system is not the same as talking about DbC, a formally specified, integrated part of a standardised language.

Last but not least, the notion of DbC includes a proof obligation. This thing is present in SPARK, but not in Ada.

Yeah, I should write an example package demonstrating DbC in Ada to match ECMA 367, 8.9 (plus visibility (= export status) and inheritance). Then we could demonstrate how Ada's type sytem and DbC can synergetically produce programs with less bugs than usual.

Wait, isn't this what SPARK is about? :-)

gb 15:08, 10 December 2005 (UTC)

CKWG: This definitly needs rewording. I don't know much about DbC, so I won't do it. 19. November 2013

It`s a Wiki
Well this is Wiki - you can allways improve the text and I would welcome that.

But note that this module originates from Computer programming/Error handling. Computer programming/Error handling is about error handling in generall - without any particular language in mind. The aim is more about telling people that errors need to be handled - and preferly in the language - then pushing DoC. More for "anti error handling trolls" then "anti Ada trolls". Yes they exitst. Programmers who belive that they can do it better then any sofisticated programming lanuguage.

Ada Programming/Error handling are only examples on how your can archive an particular technique in Ada. Have you seen the other page? Have you noticed how they share text and where they are different?


 * seen them, and I disagree with what is said about DbC, and optimization for example.

Sad that there is no Eiffel or Spark book on Wikibooks. It would really be interesting have to have Eiffel Programming/Error handling or SPARK Programming/Error handling as better example of DoC.

And have you read Design by contract? Every time I look at it there are more DbC implementations.

--Krischik T 18:08, 10 December 2005 (UTC)


 * I disagree. There is an increasing number of "me too"s, yes. How do they integrate inheritance and contracts? Where are the loop invariants? Can you write check-correct programs? Are they exception-correct? That is to say, how can you specify that the postcondition is going to be true in case of a handled exception, using these wannabe DbC systems?


 * I never said I find them any good ;-) - as far as I see it only "D" and "SPARK" realy deverve to be called a DoC language. And even there I might be wrong. It seams that you know a lot about the subject - more then me for that matter. So could you write up an article about DbC? Wikibooks is still missing one. The appropiate place for a chapter would be Computer_Programming/Design by Contract or (Not using a trademark) Computer_Programming/Programming by Contract with a link to that chapter at Computer_Programming and/or Computer_Programming. Of corse you can allways start a new book as well if you have enough material. --Krischik T 07:34, 12 December 2005 (UTC)


 * I have now added Computer_Programming/Design by Contract. (Programming by contract reminds me too much of employer/employee) The page isn't very well connected yet, I'll try to inject some links in the proper places


 * And the page has moved to Computer programming/Design by Contract, joining the other pages.


 * Writing a function in a Hoare triple is not DbC yet.


 * o.K. I'll have a try rewriting some of the remarks.


 * I tried, but where is the text??? After clicking the edit link (which takes me Computer_Programming/Error_handling/5), editing, previewing, and saving, the old text comes back. What am I doing wrong? The new text is still there when I do it again:


 * Nothing, the page cache has fooled you. You can either wait until the cache expires or click here http://en.wikibooks.org/w/index.php?title=Computer_programming/Error_handling&action=purge to purge the cache.

In Design by Contract (DbC) functions must be called with the correct parameters. This is the caller's part of the contract. If the types of actual arguments match the types of formal arguments, and if the actual arguments have values that make the function's preconditions True, then the subprogram gets a chance to fulfill its postcondition. Otherwise an error condition occours. Now you might wonder how that is going to work. Lets look at the example first:


 * gb 22:12, 10 December 2005 (UTC)


 * gb 21:37, 10 December 2005 (UTC)

Programming by Contract
Just read http://www.aechmea.de/html/german/Information01_e.htm. Since Eiffel has hogged the term "Design by Contract" they use the term "Programming by Contract" - Alltrue I hate it when companys hogg general terms for trademak it might be better to use the non protected term.

--Krischik T 18:37, 10 December 2005 (UTC)


 * In the case of Eiffel, they have created the thing. There was little O-O correctness theory of practical use before Eiffel AFAIK. Now everyone is trying to follow suit. If we, too, start using well defined terms in a sloppy manner, are we still doing it the Ada way? DbC is too valuable to be equated to just some checking in my view.


 * gb 21:51, 10 December 2005 (UTC)

Please make any Programming by Contract book generic (language agnostic)
Most programmers do not have the luxury of choosing the language they use. For several years I have been programming almost exclusively in VB6, next year I wil have to return to C++ for a while. Neither include direct support for PbC but that doesn't mean that programmers who are forced to use them can't benefit from the ideas. If PbC is introduced through the medium of a specific language, whether it is Eiffel, SPARK, or ADA busy programmers who use other languages will simply not be encouraged to apply the lessons of PbC even though quite a lot of them can be applied even in the absence of compiler support. So please separate the concepts of PbC from the language specific implementation. By the way I think that Programming by Contract is a better name than Design by Contract, especially if Betrand Meyer and co. have registered the latter as a trademark. --kwhitefoot 11:13, 12 December 2005 (UTC)


 * I have tried to follow your advice in Computer_Programming/Design by Contract. Since DbC is well thought out and integrated (criticism of arguably minor issues notwithstanding), I have stuck to DbC, in fairly general terms. Some pre/postcondition additions seem to miss quite a bit of DbC, however laudible they are. Comments etc. most welcome. gb 04:27, 15 December 2005 (UTC)

Error handling should be described as correctly as possible
I think that we should get this page correct, or else there is a risk of looking a little foolish.

However, before crossing out half of the text and adding another new half (which might not be good enough either), I'd like to discuss this.

Example:

Add the following function to Error_Handling_5 and observe that the compiler does indeed NOT help you to fullfill your contractual obligation. You'd think that calling Square_Root is all right, because all parameters are >= 0, but the compiler cannot tell this! Add this function, and see the compiler be happy:

function "**"(X: Float; E: Integer) return Float is  begin return -1.0; end "**";

Then run the program and notice Constraint_Error. Hence, as DbC requires, it is the programmer who MUST pay attention to calling a function with proper arguments. The Ada compiler cannot in general help you, even though it does some (sub)type checking.

Even if this example seems silly, absent SPARK it should prove that there is no a way for an Ada compiler to replace proper obedience to preconditions with type based magic.

So at the very least, the presentation requires rewording, and maybe a different theoretical model.

gb 07:01, 15 December 2005 (UTC)

True
A propper error handling chapter is indeed very important. There are to many false claims floating about - mostly from C programmers which allways thing they don't need support from the compiler. And if that means that DbC is not Ada then we need to say so - correctness of Computer_programming/Error_handling is more important then showing of Ada as a jack of all trades.

However In DcB or Strong-Typing I believe it is important to stess that runtime checks can be minimized. In languages without automated runtime checks you often have either to many checks (paranoid programmers adding checks anywhere) or to little checks (lazy programmers adding checks only when the problem happened at least once.


 * Could someone in the know please instruct how to edit the text and the examples after the first paragraphs of a section? There is a load of misinformation not just about DbC, but also about the pre/post of Sqrt, sorry, and I'd like to correct this. However, each time I try to edit, I get the first paragraph of the section and nothing else. What should I read/do? gb 20:08, 26 December 2005 (UTC)


 * This page is made up using transclusion, that is, including the text of other pages in it, as if they were templates. When you are hitting the edit link, you are using the one of a section that is inside of one of those pages. For editing the text after that fragments, you have to use the edit tab of this page. You will see in the wiki source where are other pages transcluded (using ), and then you can choose if you want to edit the text of this page, or the text of one of the transcluded pages. Hope this helps. ManuelGR 20:45, 26 December 2005 (UTC)


 * It has helped me, thanks. gb 23:44, 26 December 2005 (UTC)