The ASSERT / HALT value stuff previously disussed 
Author Message
 The ASSERT / HALT value stuff previously disussed

As was mentioned earlier, here are the ASSERT / HALT values which are being
used by at least two people.  It would be nice if the rest of the world would
standardize on these, too:

20..97        reserved for future
98            abstract method invoked
99            feature not yet implemented
100..119      precondition failure
120..139      postcondition failure
140..159      invariant violation
160..255      user / module defined

These, of course, assume that you are using the standard Oberon system.

Taylor Hutt
What is the metric equivalent of the US stovetop burner setting 'HI'?



Tue, 13 Jan 1998 03:00:00 GMT  
 The ASSERT / HALT value stuff previously disussed


Quote:
>As was mentioned earlier, here are the ASSERT / HALT values which are being
>used by at least two people.  It would be nice if the rest of the world would
>standardize on these, too:

Sounds good to me. We'll use these with the math libs.

Quote:
>20..97        reserved for future
>98            abstract method invoked
>99            feature not yet implemented
>100..119      precondition failure
>120..139      postcondition failure
>140..159      invariant violation
>160..255      user / module defined

Since you are using multiple numbers for preconditions, postconditions and
invariants, perhaps it would be a good idea to be more specific. Howabout
predefining a few of each, like out-of-range errors and NIL checks? If you're
making a standard, you might as well standardize it a little.

Brian Hawley



Wed, 14 Jan 1998 03:00:00 GMT  
 The ASSERT / HALT value stuff previously disussed

Quote:



>>As was mentioned earlier, here are the ASSERT / HALT values which are being
>>used by at least two people.  It would be nice if the rest of the world
would
>>standardize on these, too:

>Sounds good to me. We'll use these with the math libs.

>>20..97        reserved for future
>>98            abstract method invoked
>>99            feature not yet implemented
>>100..119      precondition failure
>>120..139      postcondition failure
>>140..159      invariant violation
>>160..255      user / module defined

>Since you are using multiple numbers for preconditions, postconditions and
>invariants, perhaps it would be a good idea to be more specific. Howabout
>predefining a few of each, like out-of-range errors and NIL checks? If you're
>making a standard, you might as well standardize it a little.

>Brian Hawley

The ranges were created for programmer convenience, mainly.  For example,
consider Files.Set(rider, file, position).  From the top of my head, there
could be the following preconditions, which I will arbitrarily number

precondition                      value
file # NIL                        160
file^ is a valid Files.File       161
pos >= 0                          162
pos <= Files.Length(file)         163

In practice, the number is mostly only useful to the programmer or the person
who is debugging the code -- the number points out to them exactly which
precondition, which they have defined, has failed.

I am of the opinion that the user/module defined numbers would be better to
specify more generic things which would occur on a frequent basis for your
programs.  However, if we, as c.l.o, can come up with some more that would be
useful, then the notation can be extended.

Taylor Hutt
Who was the first person to try truffles?



Fri, 16 Jan 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. printinng a std_logic_vector signal value in a an assert statement

2. Halt doesn't halt.

3. assert 'assert'

4. what's more efficient? retract-assert, or assert-assert

5. FS/A: Cool rare SMALLTALK stuff, don't miss out, NeXT and BeOS stuff too

6. How can I ask LV to leave my design time stuff separate from runtime stuff

7. JSObject stuff & stuff

8. Latest Fortran stuff and other stuff

9. SaveBuffer vs Position (previously posted on the french NG)

10. Regarding previously reported problems with ISE 3.3.9 for windows NT

11. Summary of COOTS 95 (previously Usenix C++ workshop)

12. Make .exe smaller (sorry, forgot it previously)

 

 
Powered by phpBB® Forum Software