nevin1@ihlpb.ATT.COM (Liber) (10/12/88)
[followups to comp.lang.misc] In article <993@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes: >From article <634@eiger.iis.UUCP>, by prl@iis.UUCP (Peter Lamb): >> In article <978@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes: >Run time checks aren't a general solution? Compiler generated run time checks may be general, but they aren't a solution. Not unless you plan on running a complete test suite (good luck writing one, *proving* it complete, and finding the time to run it from the beginning every time you make a code change) to make sure they aren't necessary at all. >They aren't even very expensive. But they are an expense, and, except for debugging purposes (I am assuming that we are talking about production code and not code that is being developed. If we are talking about development, then I agree that run time checks are valuable as a debugging aid, provided that they are implemented sensibly, such as dropping into a debugger when a run time check encounters an error instead of just bombing out of the whole program), are useless (sometimes even worse than useless). Also, most non-trivial programs have to have run time checks explicitly coded, anyway. And only through the explicit ones can the programmer do any kind of graceful handling. >At least not when compared to the alternative of buggy nonportable code. Since run time checks don't *fix* bugs but merely detect them (actually, the type of bugs that they detect are the ones where the specification does not match the actual code), the two choices are: 1. Buggy nonportable code 2. Buggy nonportable code with run time checks Of these two, I much prefer case 1 to case 2. I have a much better chance of terminating *gracefully* (and quite possibly even recovering) without the run time checks than with them. What is really wanted is an exception handler; run time checks don't even come close to being a substitute. -- _ __ NEVIN J. LIBER ..!att!ihlpb!nevin1 (312) 979-4751 IH 4F-410 ' ) ) "I catch him with a left hook. He eels over. It was a fluke, but there / / _ , __o ____ he was, lying on the deck, flat as a mackerel - kelpless!" / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
sommar@enea.se (Erland Sommarskog) (10/16/88)
Nevin J Liber (nevin1@ihlpb.UUCP) writes: >Also, most non-trivial programs have to have run time checks explicitly >coded, anyway. And only through the explicit ones can the programmer >do any kind of graceful handling. If the programmer handles the check himself, we find here another source of error. If we are really unlucky the check may be wrong. Legal index may be in the range a..b inclusive, but by mistake he writes "IF a <= i < b THEN" and during test we never get to the upper index. So leave the mechancial work of checking to the compiler. And it is easier to turn off the checks in the compiler than the hand-coded ones. Also, we get a cleaner code. As for graceful handling, what you want is some kind exception handler you can trap to. With no checks at all you just hurry on as nothing has happened, which is really dangerous. Programmer-supplied checks can be a good idea if the language supports a good way of expressing them without cluttering the code. C has assert which could be of some help. They are rather a complement to compiler-generated checks, though. Eiffel is quite interesting here. My studies of the langauge are not complete yet, but as far I understand there are very few errors that the compiler can generate checks for. I can't think of anything else than void references. On the other hand Eiffel supplies several devices for expressing permitted conditions. Most noticeable are the class invariants and the require/ensure clauses that are part of the routine interface. And when you build your system you tell can which classes that should have their checks on and which shouldn't. require/ensure clause are part of the routine interface. And you t -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP