Является ли синтаксической ошибкой деление на ноль в программировании

Виды ошибок в программах

Я учусь на своих ошибках. Ругаю себя за это, но продолжаю ошибаться. С другой стороны — это всё-таки лучше, чем не учиться совсем, и наступать на одни и те же грабли бесконечно.

При создании программ, даже простых, ошибки неизбежны. Поэтому для поиска ошибок во всех средствах разработки имеются особые инструменты для отладки. Но сегодня не об отладке и не о поиске ошибок. Сегодня о видах ошибок, которые встречаются в программах.

Итак, основных вида всего три:

• Синтаксические ошибки
• Логические ошибки
• Ошибки выполнения программы

Синтаксические ошибки в программах

Эти ошибки довольно распространены, особенно среди начинающих. Но эти ошибки — самые безобидные. Потому что компиляторы легко находят ошибки синтаксиса и указывают место в исходном коде, где обнаружена такая ошибка. Программисту остаётся только исправить её.

Синтаксические ошибки — это ошибки синтаксиса (а то бы вы не догадались))). То есть ошибки правил языка. Например, для Паскаля это будет синтаксической ошибкой:

WriteLn('Hello, World !!!')
ReadLn;

Потому что после первой строки нет точки с запятой.

Подобные ошибки очень часто совершают новички. И это вгоняет их в ступор — они пугаются и не могут понять, что же не так с их кодом. Хотя если бы они внимательно его посмотрели и прочитали сообщение об ошибке, то легко могли бы исправить её:

Потому что в сообщении чётко сказано:

Syntax error, ";" expected but "identifier READLN" found

что можно перевести как

синтаксическая ошибка, ";" ожидалось, но "READLN" найден

То есть компилятор говорит нам: я ожидал увидеть точку с запятой, а нашёл идентификатор READLN.

Логические ошибки в программах

Это самые противные и самые труднонаходимые ошибки. Программа может быть написана совершенно правильно с точки зрения синтаксиса языка, и при этом она будет неправильно работать. Потому что программист допустил где-то логическую ошибку.

И компилятор вам ничего об этой ошибке не расскажет, потому что правила языка не нарушены.

Поиски таких ошибок могут занять много времени и отнять у вас немало здоровья. Поэтому при разработке программ лучше не торопиться и стараться не допускать логических ошибок.

Пример логической ошибки:

for i := 1 to 10 do
  if i = 15 then WriteLn('i = 15');

Здесь мы сравниваем значение i с числом 15, и выводим сообщение, если i = 15.
Но фишка в том, что в данном цикле i не будет равно 15 НИКОГДА, потому что в цикле переменной i присваиваются значения от 1 до 10.

Эта ошибка довольно безобидная. Здесь мы имеем просто бессмысленный код, который не причинит никакого вреда.
Однако представьте, что программа должна выдавать какой-то сигнал тревоги, если i = 15. Тогда получится, что никакого сигнала пользователь никогда не услышит, даже если случилось что-то страшное. А всё потому, что программист немного ошибся. Вот так вот и падают ракеты и самолёты…

Распространённые логические ошибки в С++ вы можете посмотреть здесь.

Ошибки времени выполнения программы

Даже если исходный код не содержит ни логических, не синтаксических ошибок, это ещё не означает, что ваша программа безупречна. Потому что ошибки могут возникнуть в ходе выполнения программы. Например, случайно будет удалён файл, который должна читать программа, и она не сможет его найти. Если не принять мер, то программа может завершиться аварийно. А пользователям такое поведение программ очень не нравится.

Одна из самых рапространённых ошибок времени выполнения — это неожиданное деление на ноль. Пример:

Write('y = ');
ReadLn(y);
x := 100 / y;
WriteLn('100 / ', y, ' = ', x);

Что здесь такого? Всё правильно и с точки зрения логики, и с точки зрения синтаксиса. И в большинстве случаев программа отработает без каких-либо неожиданностей.

Но представьте, что пользователь введёт ноль. Что тогда будет? Правильно — попытка деления на ноль. А на ноль делить нельзя. Поэтому во время выполнения этой программы произойдёт ошибка, которая очень расстроит пользователя. Потому что в случае, например, с консольным приложением программа просто закроется, и пользователь не поймёт, что это было. Но зато поймёт, что программа — говно, и программы от этого разработчика лучше больше никогда не использовать.

В данном случае, если вы не уверены на 100%, что y будет отличаться от нуля, надо всегда делать проверку на ноль. И хороший код должен быть хотя бы таким:

Write('y = ');
ReadLn(y);
if y = 0 then WriteLn('ERROR: y = 0')
else
  begin
    x := 100 / y;
    WriteLn('100 / ', y, ' = ', x);
  end;

Ну что же. На этом с видами ошибок пока всё. Изучайте программирование и поменьше ошибайтесь.

The terms error and exception are commonly used as jargon terms, with meanings that vary depending upon the programming ecosystem in which they are used.

Conditions

This response follows the lead of Common Lisp, and adopts the term condition as a nonjudgmental way of referring to an «interesting situation» in a program.

What makes a program condition «interesting»? Let’s consider the division-by-zero case for real numbers. In the overwhelming majority of cases in which one real is divided by another, the result is another plain ordinary well-behaved real number. These are the «routine» or «uninteresting» cases. However, in the case that the divisor is zero then, mathematically speaking, the result is undefined. The program is now in an «interesting» or «exceptional» condition.

It becomes even more complicated once we take the mathematical ideal of a real number and model it, say, as an IEEE-format floating point number. If we divide 1.0 / 0.0, the IEEE standard (mostly) says that the result is in fact another floating point number, the quiet NaN Infinity. Since the result no longer behaves in the same way as a plain old real number, the program condition is once again «interesting» or «exceptional».

Classifying Conditions

The question is: what should we do when we run into an interesting condition? The answer is dependent upon the context. When classifying program conditions, the following questions are useful:

1. How likely is it that the condition will occur: certain, probable, unlikely, impossible?
2. How is the condition detected: program malfunction, distinguished value, signal/handler (aka exception handling), program termination?
3. How should the condition be handled: ignore it, perform some special action, terminate the program?

The answers to these questions yield 4 x 4 x 3 = 48 distinct cases — and surely more could be distinguished by further criteria. This brings us to the heart of the matter. We have more than two cases but only two labels, error and exception, to apply to them. Needless to say, there are many possible ways to divide the 48+ cases into two groups.

For example, one could say that anything involving program malfunction is an error, anything else is an exception. Or that anything involving a language’s built-in exception handling facilities is an exception, anything else is an error. The possibilities are legion.

Examples

End-Of-File

When reading and processing a stream of characters, hitting the end-of-file is certain. In C, this event is detected by means of a distinguished return value from an I/O function, a so-called error return value. Thus, one speaks of an EOF error.

Division-By-Zero

When dividing two user-entered numbers in a simple calculator program, we want to give a meaningful result even if the user enters a divisor of zero. In some C environments, division-by-zero results in a signal (SIGFPE) that must be fielded by a signal handler. Signals are sometimes called exceptions in the C community and, confusingly, sometimes called program error signals. In other C environments, IEEE floating-point rules apply and the division-by-zero would result in a NaN value. The C environment would be blissfully unaware of that value, considering it to be neither an exception nor an error.

Runtime Load Failure

Programs frequently load their program code dynamically at run-time (e.g. classes, DLLs). This might fail due to a missing file. C offers no standard way to detect or recover from this case. The program would be terminated involuntarily, and one often speaks of this situation as a fatal exception. In Java, this would be termed a linkage error.

Java’s Throwable Hierarchy

Java’s exception-handling system divides the so-called Throwable class hierarchy into two main groups. Subclasses of Error are meant to represent conditions from which recovery is impossible. Subclasses of Exception are meant for recoverable conditions are are further subdivided into checked exceptions (for probable conditions) and unchecked exceptions (for unlikely conditions). Unfortunately, the boundaries between these categories are poorly defined and you will often find instances of throwables whose semantics suggest that they belong in a different category.

Be Wary Of Jargon

These examples show that the meanings of error and exception are murky at best. One must treat error and exception as jargon, whose meaning is determined by the context of discussion.

Of greater value are distinguishing characteristics of program conditions. What is the likelihood of the condition occurring? How is the condition detected? What action should be taken when the condition is detected? In any discussion that demands clarity, one is better suited to answer these questions directly rather than relying upon jargon terminology.

Перейти к контенту

Persotr27, результат деления на ноль таки NaN, некоторые языки его выдают вместо исключений.
В дебаггер-то загляните. Или в консоль выводите ту же переменную, что и в текстбокс. Или вообще перед передачей числа в текстбокс преобразуйте его в текст.

30.12.2019C, C++