Good morning,I'll have to think on what you wrote, and I thank you for the feedback. Nevertheless, I'm not sure I understand your reasoning entirely (unless I'm missing something) - so, please, elaborate. To explain: to me a "programming-by-contract" always meant the perception of functions (methods) as "services" which "require" something from the caller and, in return, "ensure" something on behalf of a callee. If I were to use a HYPOTHETICAL P-B-C syntax in a C/C++ case, I could write: ========================================================================= char * strchr(const char * str, int ch) require: str != nullptr; require: ch != 0; ensure: (result == nullptr) || (result >= str && result < (str + strlen(str)) && *result == ch); { /* implementation */ } ========================================================================= Maybe this is influenced by me knowing only Eiffel as a language that has a direct support for "programming-by-contract" (I have developed another C-level one, but that's not important in this context). This, by the way, is a feature that I would ALSO like to see becoming a part of C++ standard, but I see no way of it ever becoming accepted by the C++ committee. What's the difference from the "checked exceptions" enforcement? I say it is: * In a correctly written program no precondition/postcondition (contract) or assetrion violations would ever be triggered. Any of these violations mean a bug in the program. * In a correctly written program THAT RUNS IN A PERFECT WORLD no exception would ever be thrown. There'll be no "database_exception"s to signal that the DB engine is down, no "bad_alloc"s to signal that we're out of free store, etc. * What I'm proposing is to specialise the handling of exceptions that can occur in a correctly written program running in an imperfect world. Can "io_exception" happen? Yes, due to a genuine CRC error. Can a "network_exception" happen? Yes, if the line is down. Can a "bad_cast" happen? Yes, if the program is badly written, so "bad_cast" should never be "checked". So, to recapitulate, I would want, in a perfect world, for the C++ to offer both programming-by-contract and checked-exceptions; but the two have a different purpose: * P-B-C is a tool that can aid in program verification (at compile-(!) and run-time), while * If "exception handling" if a mechanism to make sure some errors "cannot be ignored", then "checked exceptions" is a tool to ensure some of these errors "cannot be ignored at compile time". Just an example of when I may need both: ========================================================================= class db_exception { ... }; class cursor { ... }; class database { public: cursor get_first_record(void * rec) throw(db_exeption) // throws "db_exeption" on an I/O error require: rec != null;// if, on entry, "rec" is "nullptr" we have a bug in the code { ... } bool get_next_record(cursor & c, void * rec)throw(db_exeption)// throws "db_exeption" on an I/O errorrequire: c != null; // if, on entry, "c" is "nullptr", it's a bug in the coderequire: rec != null;//if, on entry, "rec" is "nullptr" we have a bug in the codeensure: (result == false) || // either the call failed... (old(c) > c); // ...or, if it succeeded, the cursor has advanced{ ... }};========================================================================= Incedentally, if I could get the C++ community interested in a "programming-by-contract", I would also consider myself happy - but that would require an extra syntax to the C++, which I have no chance of getting past the C++ committees. Thirty-five years of practical experience with two dozen languages are, naturally, no match for a bunch of well-meaning one-language experts. Thanks again for your response, and especially for talking about programming-by-contract - I did not dare to raise that subject in a C++ world for fear of being ridiculed. Andrey Kapustin
On 29/06/2020 14:49, Henry Miller via Std-Proposals wrote:On Fri, Jun 26, 2020, at 22:12, andrei--- via Std-Proposals wrote:Good morning,
You have, indeed, convinced me that the "int foo() throws(auto)" is a no-go and if it will never make it into the C++ language, the better for that; your few well-chosen examples have been informative.
However, I'm still adamand that C++ needs to allow both un-checked and checked exceptions for its practitioners, depending on their needs:
- If I'm a writer of a shared library heavy on templates, then I'll never use this weird new feature, and my code will always be a valid C++.
- If I'm a writer on a project where safety means all, I want checked exceptions even more than I want programming-by-contract.
After thinking about this for a few days I think this second statement is wrong: I think you want programing-by-contract with exceptions as one contract type. (post condition) By making exceptions a contract you unify with another part of the language instead of needing new syntax - this alone makes it more likely you can get someplace with your want. Contracts also give you more/better options for what if the exception happens anyway. Without going with contracts, checked exceptions are all or nothing which means almost nobody will retrofit them: they niche that only a few will use and thus not worth adding to the standard. With contracts you can start adding checked exceptions incrementally with choices for how to find out you are wrong, and choices for how to handle being wrong.I don't follow contracts closely (though I feel like I should), but I think joining them and improving their papers to address exceptions is a better step for you.--Std-Proposals mailing list