From 2e37ddeca3455ca19e37ef679298f36b2353b0d9 Mon Sep 17 00:00:00 2001 From: halw Date: Fri, 24 Oct 2008 15:46:03 +0000 Subject: [PATCH] Author:halw Date:2008-10-24T15:46:03.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@96 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../et-design-contract-tm-assertions-and-exceptions.wiki | 2 +- .../method/eiffel-tutorial-et/et-other-mechanisms.wiki | 2 +- .../i2e-combining-genericity-and-inheritance.wiki | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki index 861310c4..cd697d21 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki @@ -316,7 +316,7 @@ Concretely, exceptions may result from the following events:
* Assertion violation, if for a system that runs with assertion monitoring on. * Attempt to call a feature on a void reference: x.f (...), the fundamental computational mechanism, can only work if x is attached to an object, and will cause an exception otherwise. * Developer exception, as seen next. -* Operating system signal:arithmetic overfolow; no memory available for a requested creation or clone -- even after garbage collection has rummaged everything to find some space. (But no C/C++-like "wrong pointer address", which cannot occur thanks to the statically typed nature of Eiffel.) +* Operating system signal:arithmetic overfolow; no memory available for a requested creation or twin -- even after garbage collection has rummaged everything to find some space. (But no C/C++-like "wrong pointer address", which cannot occur thanks to the statically typed nature of Eiffel.) It is sometimes useful, when handling exceptions in rescue clauses, to ascertain the exact nature of the exception that got the execution there. For this it is suffices to inherit from the Kernel Library class EXCEPTIONS, which provides queries such as exception, giving the code for the last exception, and symbolic names ( [[10 Other Mechanisms#Constant_and_unique_attributes|"Constant and unique attributes"]] ) for all such codes, such as No_more_memory. You can then process different exceptions differently by testing exception against various possibilities. The method strongly suggests, however, that exception handling code should remain simple; a complicated algorithm in a rescue clause is usually a sign that the mechanism is being misused. Class EXCEPTIONS also provides various facilities for fine-tuning the exception facilities, such as a procedure raise that will explicitly trigger a "developer exception" with a code than can then be detected and processed. Exception handling helps produce Eiffel software that is not just correct but robust, by planning for cases that should not normally arise, but might out of Murphy's law, and ensuring they do not affect the software's basic safety and simplicity. diff --git a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki index 7ad82e4f..beeedb90 100644 --- a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki +++ b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki @@ -121,7 +121,7 @@ The final instruction is connected with Design by Contract™. The instructio check Assertion end -, where Assertion is a sequence of zero or more assertions, will have no effect unless assertion monitoring is turned on at the Check level or higher. If so it will evaluate all the assertions listed, having no further effect if they are all satisfied; if any one of them does not hold, the instruction will trigger an exception. +where Assertion is a sequence of zero or more assertions, will have no effect unless assertion monitoring is turned on at the Check level or higher. If so it will evaluate all the assertions listed, having no further effect if they are all satisfied; if any one of them does not hold, the instruction will trigger an exception. This instruction serves to state properties that are expected to be satisfied at some stages of the computation -- other than the specific stages, such as routine entry and exit, already covered by the other assertion mechanisms such as preconditions, postconditions and invariants. A recommended use of check involves calling a routine with a precondition, where the call, for good reason, does not explicitly test for the precondition. Consider a routine of the form diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki index a967e167..ecf12fc9 100644 --- a/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki +++ b/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki @@ -8,7 +8,7 @@ The first technique yields '''polymorphic data structures'''. Assume that in the pl: LIST [POLYGON] -the type rules imply that in a call pl.put ( "p" )the permitted types for the argument p include not just POLYGON, but also RECTANGLE (an heir of POLYGON) or any other type conforming to POLYGON through inheritance. +the type rules imply that in a call pl.put (p) the permitted types for the argument p include not just POLYGON, but also RECTANGLE (an heir of POLYGON) or any other type conforming to POLYGON through inheritance. The basic conformance requirement used here is the inheritance-based type compatibility rule: V conforms to T if V is a descendant of T. @@ -28,7 +28,7 @@ As you have perhaps guessed, unconstrained genericity, as in LIST [G] LIST [G -> ANY] -Something else you may have guessed: if ANY, introduced in this session, is the top of the inheritance structure -- providing all classes with universal features such as equal to compare arbitrary objects and clone to duplicate objects -- then NONE, seen earlier in the notation feature {NONE}, is its bottom. NONE indeed conceptually inherits from all other classes. NONE is, among other things, the type of ensure, the void reference. +Something else you may have guessed: if ANY, introduced in this session, is the top of the inheritance structure -- providing all classes with universal features such as equal to compare arbitrary objects and twin to duplicate objects -- then NONE, seen earlier in the notation feature {NONE}, is its bottom. NONE indeed conceptually inherits from all other classes. NONE is, among other things, the perceived type of the Void keyword which represents a void reference.