Ошибка range check error

ошибка

I have seen too many Delphi programmers writing quite large programs without ever activating Range, Overflow and Assertion checking. Of course, you can do that if you want, but your code will be more buggy.

So, if you allow me let me insert a parallel (bug still relevant) and to your question, in the hope to convince more programmers to enable these 3 checking right now. A word of warning also included at the end.

---

Overflow checking

This will check certain integer arithmetic operations (+, -, *, Abs, Sqr, Succ, Pred, Inc, and Dec) for overflow. For example, after a + (addition) operation the compiler will insert additional binary code that verifies that the result of the operation is within the supported range.

An «integer overflow» occurs when an operation on an integer variable produces a result that is outside the range of that variable. For example, if an integer variable is declared as a 16-bit signed integer, its value can range from -32768 to 32767. If an operation on this variable produces a result greater than 32767 or less than -32768, an integer overflow has occurred.

When an integer overflow occurs, the result of the operation is undefined and can lead to undefined behavior in the program:
• Wrap-around
The result might result in a wrapped-around value. This means that the number 32768 will be actually stored as 1 since it is 1 unit higher than the highest value we can store (32767).
• Truncation
The result may be truncated or otherwise modified to fit within the range of the integer type. For example, the number 32768 will be actually stored as 32767 since that is the highest value we can store.

Undefined program behavior is one of the worst kind of errors, because it is not an error easy to reproduce. Therefore, it is difficult to track and repair.

There is a small price to pay if you activate this: the speed of the program will decrease slightly.

IO checking

Checks the result of an I/O operation. If an I/O operation fails, an exception is raised. If this switch is off, we must check for I/O errors manually.
There is a minor price to pay if you activate this: the speed of the program will decrease, but insignificantly because the few microseconds introduced by this check is nothing compared with the millisecond-range time required by the I/O operation itself (the hard drives are slow).

Range Checking

The Delphi Geek calls this “The most important Delphi setting” and I totally agree. It checks if all array and string indexing expressions are within the defined bounds. It also checks that all assignments to scalar and subrange variables are within range.

Here is an example of code that would ruin our life if Range Checking would not be available:

Type 
    Pasword= array [1..10] of byte; // we define an array of 10 elements
…
x:= Pasword[20];       // Range Checking will prevent the program from accessing element 20 (ERangecheckError exception is raised). Security breach avoided. Error log automatically sent to the programmer. Bruce Willis saves everyone.

Enabling Runtime Error Checking

To activate the Runtime Error Checking, go to Project Options and check these three boxes:

Enabling the Runtime Error Checking in ‘Project Options’

Assertions

A good programmer MUST use assertions in its code to increase the quality and stability of the program. Seriously man! You really need to use them.

Assertions are used to check for conditions that should always be true at a certain point in the program, and to raise an exception if the condition is not met. The Assert procedure, which is defined in the SysUtils unit, is typically used to perform assertions.

You can think of assertions as poor man’s unit testing. I strongly advise you to look deeper into assertions. They are very useful and do not require as much work as unit testing.

Typical example:

SysUtils.Assert(Input <> Nil, ‘The input should not be nil!’);

But for the program to check our assertions, we need to active this feature in the Project Settings -> Compiler Options, otherwise they will simply be ignored, like they are not there in our code. Make sure that you understand the implications of what I just said! For example, we screw up badly if we call routines that have side effects in the Assert. In the example below, during Debugging when the assertions are on, the Test() function will be executed and ‘This was executed’ will appear in the Memo. However, during Release more, that text will not appear in the memo because now Assert is simply ignored. Congratulations we just made the program to behave differently in debug/release mode ☹.

function TMainForm.Test: Boolean;
begin
 Result:= FALSE;
 mmo.Lines.Add('This was executed');
end;

procedure TMainForm.Start;
VAR x: Integer;
begin
 x:= 0;
 if x= 0
 then Assert(Test(), 'nope');
end;

Here are a few examples of how it can be used:

1 To check if an input parameter is within the 0..100 range:

procedure DoSomething(value: Integer);
begin
  Assert((value >= 0) and (value <= 100), 'Value out of range');
  …
end;

2 To check if a pointer is not nil before using it:

Var p: Pointer;
Begin
  p := GetPointer;
  Assert(Assigned(p), 'Pointer is nil');
   …
End;

3 To check if a variable has a certain value before proceeding:

var i: Integer;
begin
   i := GetValue;
   Assert(i = 42, 'Incorrect response to “What is the answer to life”!');
  …
end;

Assertions can also be disabled by defining the NDEBUG symbol in the project options or by using the {$D-} compiler directives.

We can also use the Assert as a more elegant way of handling errors and exceptions in some cases, as it can be more readable and it also includes a custom message, that would help the developer understand what went wrong.

Personally, I use it a lot at the top of my routines to check if the parameters are valid.

Activating this feature will (naturally) make your program slower because… well, there is one extra line of code to execute.

Nothing comes for free

Everything nice comes with a price (fortunately a small price in our case): enabling Runtime error checking and Assertions slows down our program and makes it somewhat larger.

Computers today have lots of RAM so the slight increase in size is irrelevant, so, let’s put that aside. But let’s look at the speed, because that is not something we can easily ignore:

Type                 Disabled   Enabled
Range checking       73ms         120ms
Overflow checking    580ms        680ms
I/O checking         Not tested   Not tested

As we can see the program’s speed is strongly impacted by these runtime checking. If we have a program where speed is critical, we better activate “Runtime error checking” during debugging only. What I do, I also leave it active in the first release and wait a few weeks. If no bugs are reported, then I release an update in which “Runtime error checking” is off.

Personally, I leave the “IO checking” always active. The performance hit because of this check is microscopic.

---

Big warning:
If you have an existing project that was not so nicely written, and you activate any of the Runtime Error checking below, your program may will crash more often than usual.
No, the Runtime Error checking routines did not break your program. It was always broken – you just didn’t know. The Runtime Checking routines are now finding all those places where the code is fishy and shitty and smelly. The sole purpose of Runtime Checking is to find bugs in your program.

Умея
пользоваться массивами, условными
операторами и операторами цикла, вы
можете писать довольно серьезные
программы. При выполнении этих программ
неизбежно будут возникать критические
ошибки, приводящие к аварийному завершению
программы. Такие ошибки по английски
называются Run-time errors — ошибки времени
выполнения. Рассмотрим пока только
наиболее часто встречающиеся арифметические
ошибки:

Division
by zero — код ошибки 200;

Arithmetic
overflow — код ошибки 215;

Range
check error — код ошибки 201;

Floating
point overflow — код ошибки 205;

Invalid
floating point operation — код ошибки 207.

Ошибка
Division
by zero
— деление на ноль — возникает при выполнении
операций DIV,
MOD
и /,
когда делитель равен нулю.

Ошибка
Arithmetic overflow
— целочисленное переполнение — возникает
при выполнении арифметической операции
над целыми числами, когда результат
операции выходит за границы соответствующего
типа. Такая ошибка произойдет, например,
при выполнении программы

VAR
a,b : Word; c : Integer; BEGIN a:=100; b:=200; c:=a-b; END.

Ошибка
произошла, когда вычислилось значение
выражения a-b,
равное -100.
Мы знаем, что при выполнении операции
над операндами типа Word
результат будет иметь тип Word,
а -100 не является допустимым значением
этого типа. То обстоятельство, что это
значение мы собирались присвоить
переменной типа Integer,
не
имеет значения, т.к. ошибка произошла
до
присваивания. Интересно, что, если
описать a
и
b
как
Byte,
то ошибки не будет (см. таблицу 2 в главе
5).

Ошибка
Range
check error
— ошибка проверки диапазона — происходит
в двух случаях. Во-первых, при попытке
присвоить целочисленной переменной
недопустимое значение, и, во-вторых, при
использовании недопустимого индексного
выражения для элемента любого массива.
Проиллюстрируем оба эти случая на
простых примерах.

VAR
a,b,c : Word; BEGIN a:=$FFFF; b:=1; c:=a+b; END.

Мы
попытались присвоить переменной типа
Word
значение 65536, которое не является
допустимым для этого типа.

VAR
x : ARRAY[2..8] OF Real; i : Byte;

BEGIN
FOR i:=8 DOWNTO 1 DO x[i]:=Sqrt(i); END.

Ошибка
произошла при обращении к первому
элементу массива, который не существует.
Фактически этот второй случай полностью
аналогичен первому — мы попытались
«присвоить» индексу массива, тип
которого-2..8, значение 1.

Ошибка
Floating
point overflow
— вещественное переполнение — возникает
при выполнении операции над вещественными
числами, когда результат операции
слишком велик, или при попытке присвоить
вещественной переменной слишком большое
значение. Когда речь идет о вещественных
числах, термин «слишком большое»
следует понимать как большое по абсолютной
величине — знак числа не имеет значения.
Приведем пример программы, содержащей
такую ошибку.

VAR
r : Real; BEGIN r:=-1E20; r:=Sqr(r); END.

При
возведении в квадрат величины r
мы получим слишком большое для типа
Real
число
1E40.

Ошибка
Invalid
floating point operation
возникает в трех случаях:

1)
при вычислении корня из отрицательного
числа;

2)
при вычислении логарифма неположительного
числа;

3)
при вычислении функций Trunc и Round от
слишком большого (по абсолютной величине)
вещественного числа. Эта ошибка довольно
очевидна, и мы не станем ее иллюстрировать.

Как
же должен поступать программист, когда
при выполнении его программы возникают
ошибки? Прежде всего нужно локализовать
ошибку, то есть найти оператор, в котором
она произошла. В этом вам может помочь
среда Turbo Pascal, если в ней правильно
установлены опции
компилятора.
Опции компилятора позволяют изменять
режим компиляции и задаются в подменю
Compiler
меню Options
среды Turbo Pascal. Пока нас будут интересовать
лишь пять опций: Range
checking,
Stack
cheking,
I/O
checking,
Overflow
checking,
Debug
information.
Если они включены, то настройка среды
благоприятна для отладки вашей программы.
Если они выключены, то их обязательно
следует включить, а еще лучше задать их
непосредственно в тексте своей программы.
Опции записываются в программе в виде:

{$
буква
+
/ —
}

Каждой
опции соответствует своя буква (эти
буквы выделены в подменю Compiler
цветом), символ «+» означает включить,
а символ «-» — выключить. В программе
можно задать одну опцию, например, {$R+}
или несколько опций — {$R+,I-,S+}
. Некоторые опции можно записывать
только в самом начале программы, другие
могут размещаться в любом ее месте.

Опция
Range
checking
(R) отвечает за контроль ошибок Range
check error,
Overflow
checking
(C) — за контроль ошибок Ariphmetic
overflow,
I/O
cheking
(I) — за контроль ошибок ввода-вывода.
Смысл опции Stack
cheking
(S) будет объяснен несколько позже, а
опция Debug
information
(D) включает в код программы отладочную
информацию, что позволяет среде Turbo
Pascal при аварийном завершении программы
показать курсором оператор, в котором
произошла ошибка. Позаботьтесь, чтобы
при отладке программы перед первым ее
оператором была строка {$R+,C+,I+,S+,D+}
— это поможет вам найти и устранить все
ошибки. Некоторые неопытные программисты
выключают эти опции, тогда программа
не прерывается при некоторых ошибках,
а продолжает выполняться, на этом
основании делается вывод, что программа
верна. Это самообман — программа
выполняется, но выполняется неправильно
и никак не сообщает об ошибках.

Соседние файлы в папке Учебники

• #
• #

← →
San1712
 
(2007-12-01 06:58)
[0]

---

← →
homm ©
 
(2007-12-01 08:21)
[1]

---

← →
Kolan ©
 
(2007-12-01 09:54)
[2]

Скорее всего ты вылез за границы массива. Массивы есть в программе?

---

← →
Igor Zorkov ©
 
(2007-12-01 10:00)
[3]

---

← →
Kolan ©
 
(2007-12-01 10:03)
[4]

> В меню Tools>Debugger Options>Language Exceptions>Add&#133
> добавить ERangeError

А это зачем делать, объясни?

---

← →
Igor Zorkov ©
 
(2007-12-01 10:24)
[5]

---

← →
Anatoly Podgoretsky ©
 
(2007-12-01 10:53)
[6]

> Igor Zorkov ©   (01.12.07 10:24) [5]

Это не объяснение

---

← →
Igor Zorkov ©
 
(2007-12-01 11:07)
[7]

---

← →
Anatoly Podgoretsky ©
 
(2007-12-01 11:15)
[8]

Это не ошибка компилятора.

> во время выполнения программы

во время выполнения программы компилятор не работает.

---

← →
Igor Zorkov ©
 
(2007-12-01 11:18)
[9]

---

← →
Anatoly Podgoretsky ©
 
(2007-12-01 11:45)
[10]

---

← →
Anatoly Podgoretsky ©
 
(2007-12-01 11:47)
[11]

Ему трудно помочь, поскольку он говорит, что ошибка возникает там, где нет ошибки. Нужно чудо.

---

← →
Kolan ©
 
(2007-12-01 11:51)
[12]

> На мой взгляд все очень просто

Я спросил лиш по тому что ваш код и без этой настройки сработает нормально, но автор незнает где его писать у неоже ошибка в другом месте возникает&#133

---

← →
Anatoly Podgoretsky ©
 
(2007-12-01 11:57)
[13]

> Скорее всего ты вылез за границы массива. Массивы есть в
> программе?

Эта ошибка возникает для любых диапазонов, но не только в массивах.

---

← →
Kolan ©
 
(2007-12-01 12:52)
[14]

> Эта ошибка возникает для любых диапазонов, но не только
> в массивах.

Из опыта моего обычно дело в массивах(строках)&#133

---

← →
Юрий Зотов ©
 
(2007-12-01 12:58)
[15]

---