Re: Assertion Error

Re: Assertion Error

[Matthew Heaney]

In article <6b3oi8$osq$1@gte1.gte.net>, "Larry Torres"
<ltorres@networkmachines.com> wrote:

>Got a problem:
>
>  When compiling code being ported from another platform, we get an
>"assertion error".   We are using the Rational VADS system on Solaris.   Can
>someone explain to me what the meaning is and what we might  possibly do to
>remedy the problem?

It means you found a compiler bug.  

The Rational compiler is a computer program, like any other.  A common
technique is to insert an assertion in the code, to assert that the state
has a specific value.  You do this to catch things you missed, or to catch
changes that occur during maintenance.  The code looks something like this:

procedure Op (...) is
begin
   <do some stuff that changes the state>
   Assert (X = 10);
...

X should have the value 10; if it doesn't, then something is seriously
wrong, and you want to know about it.  The subprogram Assert will raise the
exception Assertion_Error, because the predicate is false.

Figure which module is causing the compiler to crash, and report the error
to a Rationale representative.  Then get them to fix their compiler.  You
paid probably 20K+ for that environment, so you have the right to expect
that it works!

Re: Assertion Error

[Dale Stanbrough]

"Got a problem:
 
   When compiling code being ported from another platform, we get an
 "assertion error".   We are using the Rational VADS system on Solaris.  
Can
 someone explain to me what the meaning is and what we might  possibly do
to
 remedy the problem?"


You make lots of assertions about programs when you write them. Most are
in the form of type declarations ('this variable is used to hold integer
values'). Some are about the valid range of values it may hold ('this
variable can only have values b/w 1 and 10'). Other things you may
want to assert may not be directly expressed using language features
but can be in the form of a boolean expression (e.g. 'this pointer is now
non null'). Somewhere, some clever person has put an assertion in your
code, and now some fundamental assumption that they made (either about
the environment, or how the program is to work) has been broken, and
your software is kindly telling you about it.

Typically assertions look like a procedure call...

	assert (ptr /= null);
	
	assert (x in 1..40);
	
	assert (present (language_list, "Ada"));

and raise an exception when the boolean expression evaluates to false.

Dale

Reusability and assertions (Was: Assertion Error)

[Michel Gauthier]

In article <6b64u1$cjd$1@goanna.cs.rmit.edu.au>, Dale Stanbrough,
<dale@goanna.cs.rmit.edu.au>, replying to :

>>  "Got a problem:
>>     When compiling code being ported from another platform, we get an
>>   "assertion error".   We are using the Rational VADS system on Solaris.  
>>  Can someone explain to me what the meaning is and what we might  possibly do
>>  to remedy the problem?"

 wrote:

>>  You make lots of assertions about programs when you write them. Most are
>>  in the form of type declarations ('this variable is used to hold integer
>>  values'). Some are about the valid range of values it may hold ('this
>>  variable can only have values b/w 1 and 10'). Other things you may
>>  want to assert may not be directly expressed using language features
>>  but can be in the form of a boolean expression (e.g. 'this pointer is now
>>  non null'). Somewhere, some clever person has put an assertion in your
>>  code, and now some fundamental assumption that they made (either about
>>  the environment, or how the program is to work) has been broken, and
>>  your software is kindly telling you about it.

I can't consider raising Assertion_Error in a reusable component to be
clever programming.

Any bad functioning shall be specified and raised in the form of an exception.
The spirit is "the service coundn't be achieved", whichever the reason but
ordinarily some intrinsicly impossible case, independently of the
programmer's work.

Assertion checking shall be an additional process that is inserted to detect 
programming errors, events that are essentially different from "the service
coundn't be achieved".

In this sense, assertion checking should not report any other information
than "a priori, you have no responsibility on the crash, contact the
maintenance". I guess it is better to trace assertion failures than to make 
the first occurrence raise anything.

Of course, this applies to reusable parts or programs, not to
project-specific ones.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone + 33 5 55 43 69 73
fax +33 5 55 43 69 77
----------          ----------          ----------          ----------
Les concepts, c'est comme les chats : s'ils se rencontrent, ils se battent.
Concepts are like cats : if they meet, they fight.
----------          ----------          ----------          ----------