Обработка ошибок

С развитием человечества технологические риски увеличиваются. Чем больше техника входит в нашу жизнь, тем выше цена, которую мы платим технические ошибки — как допущенные по недомыслию, так и преднамеренные. За примерами далеко ходить не надо. Шведская биржа была парализована лотом на покупку -6 фьючерсов: число -6 было истолковано как 4294967290. Стоимость получившегося лота в 131 раз превысила ВВП Швеции. В другом случае француженка получила счет на 12 квадриллионов евро. А вот небезобидный случай: авария ракеты «Ариан-5» из-за ошибки в программе системы инерциальной ориентации. Некорректное преобразование 64-битного числа с плавающей точкой в 16-битное целое со знаком принесло ущерб в сотни миллионов долларов.

В программах не лишне иметь и подушки безопасности, и предохранители, и «защиту от дурака».

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

Можно с горькой иронией констатировать, что «формальные методы борьбы за правильность и надежность чаще всего дают и формальные же результаты». Но у формальных методов нет разумных альтернатив. Это единственный способ переложить проверку правильности программ с человека на компьютер. Без формальных методов компьютер не умеет принимать решения и помогать в нахождении ошибки.

Формальные методы не отменяют необходимость проверки результатов работы и необходимость отладки. В отсутствие этих методов спасает только дотошная отладка: бит за битом, байт за байтом, как во времена всеобщего программирования на ассемблере. Надо быть заранее готовым, что с ростом размера программ растёт и трудоёмкость отладки, но не в линейной прогрессии.

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

// признак ошибки — нулевой указатель
int* ptr = get_ptr (parameter);
if (ptr)
	*ptr = value;
else
	cout << "ошибка: нулевой указатель\n";

   ;			throw;
	push      0
	push      0
	call      @_ReThrowException$quipuc

	call      @@_CatchCleanup$qv

В языке Rust другой подход к обработке ошибок. Проверки правильности полученных из функций значений легковесны, делаются на том же уровне, что и основные вычисления. Функции, которые могут вернуть ошибку, возвращают значение типа Option, Option<&T> или Result. Это обёртка над основным типом T.

Option<&T> (обёртка для адресов) для своей реализации дополнительной памяти не требует, признаком ошибки является нулевой указатель.

Option хранит в себе собственно объект типа T плюс признак ошибки. Размер Option — это сумма размера T, размера признака ошибки (не менее 1 байта) и байтов, необходимых для выравнивания:

размер (Option) = размер (T) + 
      размер (признак ошибки) + байты выравнивания

Result хранит в себе признак ошибки и, в зависимости от наличия ошибки, либо объект типа T, либо объект типа "ошибка". Размер Result — это сумма большего из размеров T или E, признака ошибки (не менее 1 байта) и байтов, необходимых для выравнивания:

размер (Result) = max (размер (T), размер (E)) +
      размер (признак ошибки) + байты выравнивания

Объекты типов Option и Result занимают дополнительную память. Небольшую, да занимают, это является недостатком этого метода обработки ошибок. Если тип T — это целое число, то функция, возвращающая объекты типов Option или Result, не сможет возвратить результат только в регистре. В отличие от функции, возвращающей целое число без признака ошибки:

   MOV  EAX, результат
   RET	; возврат

В Haskell обработка ошибок возложена на монады Maybe и Either. Монада Maybe либо возвращает значение (Just), либо не возвращает (Noting). Монада Either аналогична Maybe, только в случае неудачи вместо Nothing позволяет уточнить причину ошибки. Монады Maybe и Either служат тем же целям, что и типы Option и Result в языке Rust. Что-то подсказывает мне, что и их реализация на уровне машинного кода аналогична.

Обработка ошибок малой кровью

В Rust признак ошибки надо как-то передать в вызывающую функцию. Насчёт некоторых накладных расходов могут возразить: «А что вы хотели? Надёжность или экономию на пару байтов? Вам шашечки или ехать?». Есть идея поменять сами принципы проверки ошибок. Сменить не тактику, а стратегию. Чтобы «и шашечки, и ехать».

Принятый в Rust способ проверки основан на проверке формальной правильности значений уже готовых объектов. Т.е. отработала какая-то функция, записала своё значение и лишь потом приступают к проверке этого значения — тем или иным способом.

Но функцию лучше сразу «схватить за руку» до того, как она успела записать результат. Надо заставить сами функции, выдающие значения, проверять правильность собственной работы и сигнализировать об ошибках. Функция выдаёт либо правильное значение, либо ошибку, возможно с кодом этой ошибки. Т.е. смещаем акцент с объектов, хранящих своё ошибочное состояние (что, как правило, требует дополнительной памяти) на функции, которые хранят информацию об ошибках во временной (не расходуемой) памяти: либо в регистрах и флагах процессора, либо в регистре EIP, который адресует выполняемую команду, а значит идентифицирует выполняемую ветвь подпрограммы — либо успешную, либо ошибочную.

Способы реализации мы рассмотрим ниже, потому что выбранные способы не повлияют на синтаксис и семантику. Все они воплощают единый подход: в успешном случае возвращается значение, в случае ошибки управление передаётся на код, обрабатывающий ошибку, при этом регистр EAX содержит код ошибки. В проектируемом языке будет использована типизация Хиндли-Милнера, в которой объекты создаются инициализацией. Поэтому в случае ошибки инициализация не состоится и объект существовать не будет.

Функции, которые выдают свои значения, можно разбить на две категории. Одни всегда гарантированно выдают правильные значения, работа других не всегда надёжна. Например, вычисление синуса или косинуса всегда корректно: что бы ни подали на вход этой функции, всегда будет правильное значение на выходе. А вот функции вычисления тангенса и котангенса — потенциально ненадёжны: не любое значение, поданное на вход, корректно. Область определения таких функций имеет «изъятия». Следовательно, эти функции помимо правильных значений могут выдавать ошибки.

Примечание. Д.Ю. Караваев фразу «вычисление синуса или косинуса всегда корректно» прокомментировал так: «Увы, в нашем несовершенном мире это не так: при порче памяти вместо числа IEEE-754 на вход FPU подается мешанина нулей и единиц в виде «не числа» и синус/косинус также дадут исключение».

Поскольку функция с потенциально отсутствующим значением сопровождается специальным ключевым словом (допустим, ключевым словом «ненадёжная»), то появляется возможность сделать проверки на ошибки обязательными. Т.е. правила языка в принудительном порядке обязывают производить эти проверки, иное компилятор не позволит.

Примечание. Синтаксис описания функций всё ещё не устоялся, поэтому привести пример, как будет выглядеть определение функции как с ключевым словом «ненадёжная», так и без него пока не представляется возможным. Вероятно, он будет выглядеть так:

    // Определение функции — начало
    . . . ненадёжная . . .
    // Тело функции
    // Код, предшествующий обнаружению ошибки


    // передаём характеристику ошибки от этой функции в вызвавшую
    ошибка = получить значение характеризующее ошибку ()
    )    // Определение функции — конец

 Как это выглядит в программе? Пусть f, g, h — ненадёжные функции, тогда:

Любая ошибка, случившаяся при вызове f, g или h, приводит к тому, что ветвь вычислений до ключевого слова «при ошибке» немедленно прекращается и начинается выполнен кода между ключевым словом «при ошибке» и закрывающей скобкой. Если ошибка произошла при выполнении h, то g и f уже не выполняются. Если ошибка произошла при выполнении g, то f не выполняется.

В общем виде синтаксис блока проверки ошибок таков:

(   // Тело функции, вызывающей ненадёжные фукции
    // вычисления, которые используют ненадёжные функции, 
    // но гарантируют формально правильный результат
    при ошибке
    // реакция на ошибки
)

Примечание. Синтаксис конструкции обработки ошибок не понравится любителям LL(0)-грамматик. Но он краток, что соответствует философии языка.

Эти блоки могут быть внутри друг друга:

(
    // ветвь 1
    (
         ветвь 1.1
     при ошибке
         ветвь 1.2
    )
     при ошибке
    // ветвь 2
    (
         ветвь 2.1
     при ошибке
         ветвь 2.2
    )
)

В рассмотренном выше примере сразу три функции f, g и h могут стать источниками ошибок. Но какая именно и от какой поступил код ошибки — непонятно. Если важно знать источник ошибки, то проверку ошибок надо разнести в разные блоки:

tmp = 
( . . .
    h(x)
    при ошибке
    // реакция на ошибку в h
)
tmp =
( . . .
    g(tmp)
    при ошибке
    // реакция на ошибку в g
)
y =
( . . .
    f(x)
    при ошибке
    // реакция на ошибку в f
)

Функция, которая при определённых условиях может выдать некорректный результат, сопровождается ключевым словом ненадёжная. Тогда в её теле при этих определённых условиях записывается ошибка = <код ошибки> или просто ошибка, если кода ошибки нет. «Ошибка» — это ещё одно ключевое слово.

Ключевые слова ненадёжная и ошибка идут в паре, их раздельное употребление является синтаксической ошибкой. Функция, проверяющая ошибки, сама может быть ненадёжной и быть источником ошибок. Например, получив сигнал об ошибке от какой-то вызванной функции, она может передать его дальше в вызывающую функцию:

( ... ненадёжная ...     // определение ненадёжной функции
    f(x)	         // вызов ненадёжной функции f(x)
    при ошибке
    ошибка = код ошибки  // код ошибки, полученный из f(x)
)

Ненадёжная функция не может быть употреблена иначе, как внутри конструкции обработки ошибок. Вызов ненадёжной функции за пределами такой конструкции вызывает синтаксическую ошибку. Таким образом обеспечивается гарантированная, а не факультативная проверка наличия ошибок. Это не серебряная пуля, но способствует повышению надёжности программ.

Функция, вызвавшая ненадёжную функцию, не «наследует» это свойство. Любая функция остаётся формально надёжной, если не возвращает признак ошибки, даже если в своём теле она вызывала ненадёжные функции.

Предложенная конструкция позволит проверять обычные арифметические операции на переполнения или деление на ноль без лишних нагромождений:

y =
( ...
    m * n + p / q - r
    при ошибке
    // реакция на ошибки в цепочке вычислений
)

Ненадёжность является одним из признаков, характеризующих функции. Нельзя вызвать по указателю ненадёжную функцию как надёжную. Хотя обратное возможно.

// так правильно:
указатель на ненадёжную функцию = указатель на надёжную функцию
// так не правильно:
указатель на надёжную функцию = указатель на ненадёжную функцию

...
; ветвь алгоритма для выдачи правильного результата
   CLС                   ; очистка флага, нет сигнала об ошибке
   RET                   ; возврат из функции
...
; ветвь алгоритма, сигнализирующая об ошибке
   MOV	EAX, error_code  ; код ошибки
   STС                   ; установка флага, сигнал об ошибке
   RET                   ; возврат из функции

...
   CALL	func_334         ; вызов ненадёжной функции
   JC	ERROR_253        ; переход на обработку ошибки
   MOV	result_334, EAX  ; действия при отсутствии ошибки

push bp
mov bp,sp

mov sp,bp
pop bp
ret 

call функция
jmp ошибка
... продолжаем безошибочное выполнение.

call открывающая скобка
jmp это_не_выражение_в_скобках
call выражение
jmp ошибка_выражения_в_скобках
call закрывающая_скобка
jmp ошибка_нет_закрывающей скобки
... продолжение разбора 

Дополнение к предыдущему подзаголовку

Так получилось, что Дмитрий Юрьевич, описав мне проверку в предыдущем подзаголовке, получил возможность посмотреть исходники ПРОЛ-2. Это было непросто, потому что они были записаны на 5-дюймовых дискетах. Поди сейчас найди для них дисководы!

И оказалось, что в ПРОЛ-2 это было реализовано по другому. Почти 30 лет прошло — неудивительно, что детали стёрлись. Но поскольку описанный в предыдущем подзаголовке метод тоже является работающим вариантом, то убирать это из статьи не стоит. Дальше — слово Д.Ю. Караваеву.

Память меня все-таки подвела. Послать на 3 байта — это в случае отрицательного ответа (иначе зачем же грубить :)) Поэтому, неверный ответ задавался так:

        POP BP  
        ADD BP,3
        PUSH BP
        RET

При этом параметры через стек в трансляторе вообще не задавались и регистр BP не использовался в других целях. Теперь по исходным текстам это начало все вспоминаться. Вот пример одного из почти 200 модулей транслятора (разбор составного оператора): 

СоставнойОператор:
        MOV ВИД,0Ah
        CALL IM11
        PUSH ССЫЛКА_СОСТ
        MOV ССЫЛКА_СОСТ,0
M1:   CALL Блок
        JMP M6 ; Это Блок
M2:   CALL Выбор
        JMP M6 ; Это Выбор
M3:   CALL Переключатель
        JMP M6 ; Это Переключатель
M4:   CALL Цикл
        JMP M6 ; Это Цикл
M5:   CALL Ожидание
        JMP M6 ; Это Ожидание
MK:   CALL IM12
        POP ССЫЛКА_СОСТ
        POP BP  ; НЕ НАЙДЕНО НАЧАЛО ОПЕРАТОРА
        ADD BP,3
        PUSH BP
        RET
M6:   CMP ССЫЛКА_СОСТ,0
        JZ M7
        MOV ВИД,57H
        CALL IM11
        MOV AX,ССЫЛКА_СОСТ
        CALL IM17
M7:   POP ССЫЛКА_СОСТ
        MOV ВИД,59H
        CALL IM11
        RET

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

Сокращение числа переходов в общем случае — благо. В одной уважаемой компании на собеседовании соискателям предлагали задачу, направленную на то, чтобы избежать лишних переходов. Это не блажь работодателей, они знают, что им надо: они разрабатывают процессоры. Хотя с переходами задача решается быстрее и короче.

PUSH <адрес обработчика ошибок>

✅  2019/01/20 18:48, utkin          #0 

В C++ проверка ошибок основывается на конструкции try — catch — throw. Недостатки:
— Тяжеловесность. — Необязательность проверки: программист её может опустить и компилятор этого не заметит.

Монады Maybe и Either служат тем же целям, что и типы Option и Result в языке Rust.

Например, вычисление синуса или косинуса всегда корректно: что бы ни подали на вход этой функции, всегда будет правильное значение на выходе.

Поскольку функция с потенциально отсутствующим значением сопровождается специальным ключевым словом (допустим, ключевым словом «ненадёжная»), то появляется возможность сделать проверки на ошибки обязательными. Т.е. правила языка в принудительном порядке обязывают производить эти проверки, иное компилятор не позволит.

✅  2019/01/21 11:05, Автор сайта          #1 

RTTI? Не, не слышал...

разные функции могут давать разные ошибки и по нескольку сразу. Какие будем проверять?

если бы он сам об этом знал, то никогда бы эти самые ошибки не стал бы делать в своих программах, верно?

первое, что я вижу в Вашей системе — фатальные тормоза.

Д.Ю. Караваев: я вообще не могу заметить изменение скорости выполнения от использования данных команд. Вероятно, оно тоже составляет малые доли процента.

✅  2019/01/21 11:36, kt          #2 

✅  2019/01/21 13:02, utkin          #3 

Три совершенно разных пункта опровергается одним доводом. Логика? Не, не слышал.

А почитать то, что написано выше? Не, не надо. Не читать же сюда пришёл, а критиковать.

Но Вашем языке «Валентина» будут программировать только сильные люди, у которых файлы всегда прочитаются читаются. Даже если диск уже десять лет, как сломался и лежит на свалке. К чему проверки сильным людям?

А почитать про замедление на доли процента в трансляторе PL/1? А зачем?

Т.е. та же идея — спрятать все проверки правильности внутрь подпрограммы и не заставлять проверять ошибку на верхних уровнях, уже тогда витала в воздухе. В Алголе-62 можно было передавать метку как параметр.

✅  2019/01/21 16:02, kt          #4 

Ещё раз — Вы предлагаете делать проверку, которой сейчас нет. Это не доли процента.

Чем это отличается от try-except? Только формой выражения в программе. Механизм работы тот же.

✅  2019/01/21 18:20, utkin          #5 

Тем, что в Алголе и PL/1 это появилось на 30 лет раньше.

✅  2019/01/21 18:36, utkin          #6 

✅  2019/01/25 23:50, Автор сайта          #7 

• Она предлагает унифицированный и универсальный механизм. Ничего не придётся изобретать, всё единообразно.
• Эта проверка обязательна, это исключает «забывчивость», повышает качество кода (почитайте блог компании-производителя PVS Studio, о «забытых» проверках нередко пишут). Много ли языков, где такая проверка обязательна?
• Вообще не требует никакой дополнительной памяти, никаких дескрипторов, как в Rust. Проверка задействует регистры, а не память.
• Генерирует минимально возможный машинный код.

#include <stdio.h> 
int  F (int  arg) {
	if (arg == 0)
		throw;
	return  arg;
};
main() {
	try {
		printf("Good: %i \n", F (0));
	}
	catch (...) {
		printf("Bad\n");
	}
	return  0;
}

   ;	int  F (int  arg) {
	push      ebp
	mov       ebp,esp
	push      ebx
	mov       ebx,dword ptr 
   ;		if (arg == 0)
	test      ebx,ebx
	jne       short @2
   ;			throw;
	push      0
	push      0
	call      @_ReThrowException$quipuc
	add       esp,8
   ;		return  arg;
@2:	mov       eax,ebx
   ;	};
	pop       ebx
	pop       ebp
	ret 
   ;	main() {
	push      ebp
	mov       ebp,esp
	add       esp,-36
	mov       eax,offset @@_$ECTC$@main$qv
	push      ebx
	push      esi
	push      edi
	call      @__InitExceptBlockLDTC
   ;		try {
	mov       word ptr ,8
   ;			printf("Good: %i \n", F (0));
	push      0
	call      @@F$qi
	pop       ecx
	push      eax
	push      offset s@
	call      @_printf
   ;		}
	mov       word ptr ,0
	add       esp,8
	jmp       short @7
   ;		catch (...) {
   ;			printf("Bad\n");
	push      offset s@+11
	call      @_printf
	pop       ecx
   ;		}
	mov       word ptr ,16
	call      @@_CatchCleanup$qv
   ;		return  0;
@7:	xor       eax,eax
	mov       edx,dword ptr 
	mov       dword ptr fs:<0>,edx
   ;	}
	pop       edi
	pop       esi
	pop       ebx
	mov       esp,ebp
	pop       ebp
	ret

   ;			throw;
	push      0
	push      0
	call      @_ReThrowException$quipuc

	call      @@_CatchCleanup$qv

Да, в языках много маркетинга.

✅  2019/01/26 08:30, utkin          #8 

Функция «прочитать текстовый файл» возвращает строку с текстом. Что она должна вернуть, если файл не читается? Пустую строку?

А если использует значения-исключения, как признак ошибки, то теряется универсальность и обязательность проверки. Функцию можно будет вызвать, но результат не проверить.

Эта проверка обязательна, это исключает «забывчивость», повышает качество кода (почитайте блог компании-производителя PVS Studio, о «забытых» проверках нередко пишут). Много ли языков, где такая проверка обязательна?

Вот поэтому программисты C++ не советуют использовать исключения, как вещь повседневного обихода, пишут о «боли, которая может возникнуть, например, в C++ при использовании try-catch».

✅  2019/01/26 18:52, Автор сайта          #9 

проблемы должны решать специалисты

функция может возвращать структуру из полей:
1) Значение
2) Результат операции

Вы утверждаете, что Ваш метод постоянной проверки на ошибку будет "легче", чем использование блоков проверки исключения по необходимости?

✅  2019/01/26 19:46, Comdiv          #10 

✅  2019/01/26 23:34, Автор сайта          #11 

1. Как функция должна сообщать об исключении?

2. О возможности или запрете транзитной передачи исключений от вызываемых функций к вызывающей.

3. О поддержке в языке развития кода, когда, например, функции, изначально помеченной как гарантированно выполняемой, потребовалось вызвать функцию, выполнение которой с исключением не позволяет выполнить контракт.

4. Сколько функций, по Вашему мнению, в среднестатистическом коде будут помечены как гарантированно выполняемые, и как это должно отразиться на ЯВУ?

5. Как обрабатывать функции, которые в общем случае не могут завершиться без исключений, но в предоставленных условиях должны?

6. Будут ли ошибки программы отделены от ошибок данных?

✅  2019/01/27 04:26, Comdiv          #12 

1. Положить в регистр аккумулятор

2. Если вызвавшая функция не может или не должна обрабатывать ошибку, она тогда сама является ненадёжной и формирует значение, характеризующее ошибку. Тогда этим займётся функция, вызвавшая вызвавшую

3. если логика работы позволяет подпрограмме обойтись без результатов ненадёжной функции, то всё хорошо

4. Значительная часть функций ненадёжна...

5. Не понял сути вопроса. Они либо правильно работают, либо неправильно. И и том, и о другом мы должны знать

  sum = add(a % 8, b % 16)

  sum = add(any1, any2)

6. окончательное мнение ещё не выработано.

✅  2019/01/27 05:48, MihalNik          #13 

5. Как обрабатывать функции, которые в общем случае не могут завершиться без исключений, но в предоставленных условиях должны?

Не понял сути вопроса. Они либо правильно работают, либо неправильно.

✅  2019/01/28 07:41, utkin          #14 

Но в языках высокого уровня сразу после «if» идёт ветка «then». Обязательно идёт «then»! Хотя казалось бы: к чему такая обязаловка? Может, я ещё что-то хочу сделать между «if» и «then»?

Нет, это не самодурство, это просто разумная дисциплина, уменьшающая вероятность ошибки.

Если Вы простив обязательности проверки ошибок, значит Вы считаете допустимым игнорировать поступающие сообщения об ошибках в программе.

Если функция не «специалист», она заявляет, что не уполномочена, объявляет себя ненадёжной и отправляет шар по иерархии, функции-«начальнице».

Конечно может. Почти во всех языках программирования может.

А кто неаккуратен, тот конечно будет возмущаться: «Караул, меня проконтролировали, что я не смыл за собой в туалете! Меня ограничавают в творчестве!».

✅  2019/01/28 13:28, Автор сайта          #15 

Я имел ввиду вид в ЯВУ

ошибка = . . .

исключения могут передаваться через несколько "этажей" вызовов, как во многих других языках?

при ошибке	// ветвь обработки ошибок
    ошибка = получить значение характеризующее ошибку ()
		// передаём характеристику ошибки от вызванной функции в вызвавшую

Не получится ли так, что при проектировании сверху вниз нужно обязательно задавать ненадёжность, потому как сложно предвидеть какие функции будут использованы при воплощении?

• функция обрабатывает ошибки вызванных функций, т. е. имеет ветвь обработки ошибок «при ошибке»,
• сама не является источником ошибок и не передаёт информацию об ошибке по иерархии сверху вниз:

  ошибка = ...

Язык обяжет и такой код заворачивать в обработчик ошибок? Пример:
sum = add(a % 8, b % 16)

i32 sum(i31, i31){. . .}  // надёжная
i32 sum(i32, i32){. . .}  // ненадёжная

захотите отделять, расскажите, пожалуйста, как именно это будет происходить. В представленном подходе неясно, как это может быть сделано.

✅  2019/01/28 16:29, Автор сайта          #16 

Дичайший аргумент. Может быть такая обязаловка потому что это ПРАВИЛО языка?

Если же лично я складываю а + б, я не буду его проверять на ошибки. Потому что если туда не поместится результат числа, то проблема не в РЕАЛИЗАЦИИ, а в ПРОЕКТЕ.

Операция деления САМА генерирует исключение... Ну так в чем проблема с которой Вы боретесь?

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

в JavaScript делить на нуль можно

Не понятно, почему Ваша система будет лучше имеющихся решений.

✅  2019/01/28 16:42, utkin          #17 

Хороший вопрос. Честно говоря, дальше того, что описано выше, пока не думал, но вопрос про «многоэтажность» подталкивает к этому.

Вы мне, можно сказать, открыли глаза :), теперь я думаю, что в принципе функция может пропустить проверку ошибок, но она тогда обязана обеспечить транзит информации об ошибке в функцию, которая её вызвала.

Как тогда выглядит такая «транзитная» функция? Ключевое слово «ненадёжная» остаётся при ней, ветвь обработки ошибок («при ошибке») исчезает из кода на ЯВУ, но остаётся в неявном виде в сгенерированном ею машинном коде.

Ещё раз скажу: Вы задаёте хорошие вопросы.

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

Вот видите, это Вам показалось дикостью. Потому что давно привыкли к этому и это давно стало правилом. А до появления Фортрана это не было правилом. Так вот обязательность проверки ошибки тоже должна стать правилом. И к этому можно привыкнуть, как к «then» после «if»

ТЗ содержит задание: посчитать среднюю сумму чека, тип double. ТЗ не разжёвывает Вам реализацию.

Ваша реализация: первая функция вычисляет сумму всех чеков (тип double), вторая — количество всех чеков (тип unsigned int). Т.е. Вы лично складываете а + б и не проверяете на ошибки. Потом первое делиться на второе — и вот вам результат.

Когда нет системы проверки переполнений и Вы видите какие-то цифры, то предъявляете заказчику: ТЗ выполнено. Когда есть проверка переполнений, то видите, что количество чеков у Вас зашкалило, обнулилось, а потом опять начало расти. Это простимулировало Вас найти ошибку в рассуждениях и подобрать для количества чеков более вместительный тип. Проверка ошибок явилась Вам, как вразумление, ибо слаб человек и ему свойственно ошибаться.

Вот она проблема, с которой я борюсь: в одном случае реагируют на ошибки, а в другом нет! Как же найти единое решение? Да я его предложил.

1) Какой ценой? Я предложил минимальнейшую цену.

2) Установить источник могут, но не устанавливают!

Не приводите этот язык в пример, тут имеет место быть другая философия

Как звать-то Вас при крещении?

✅  2019/01/28 18:24, Автор сайта          #18 

о разнице между тем, что есть и о тормозах, которые будет порождать Ваша система обработки ошибок.

как пользовательская функция понимает, что она допустит ошибку?

Что должна делать рекурсия?

Вы часто даёте ссылки на разные ресурсы. В основном, конечно, мусор

Но вот я дал ссылку на какой-то такой механизм в стандарте С++ 14. Чего бы не посмотреть, как люди до Вас взяли и изобрели колесо?

Вы задаёте хорошие вопросы.

А как же я :)? Рекурсия, мужик! Я не спрашивал так, исходя из наших прошлых бесед, был уверен, что Вам это и так ясно :).

Как это компилятор сможет предсказать?

Есть стандарт. Хотите новое, без проблем, но без торговой марки if. И это даже не мой личный каприз.

Это вообще не факт.

это МОИ ОШИБКИ и они не должны обрабатываться в runtime.

отмазка типа "Мы не такие" — это не защита, а бегство от аргументов.

✅  2019/01/28 19:06, Comdiv          #19 

 ошибка = . . .

атрибут ненадёжности не является обязательным, от него можно избавиться

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

if (f) {
   a = rand();
   b = -rand();
} else {
   a = a1 % 43;
   b = b1 / 1024;
}
sum = add(a, b)

А с чем связан Ваш вопрос насчёт отделения ошибок подпрограмм и ошибок данных?

try {
    a = add(inputA, inputB);
    p = mul(a % 8, inputB /* % 8 ошибка в программе*/);
    log(p);
} catch {
    log("недопустимые входные данные")
}

✅  2019/01/29 07:46, utkin          #20 

Я описал в ассемблерных кодах, почему исключения в C++ тяжеловесны. Описал, какие машинные коды генерирует моё предложение. Я свои слова подкрепляю какими-то фактами, а Вы — нет.

Когда вы преобразуете строку в число и встречаете там букву, то сами принимаете решение: это ошибка

Умеете Вы льстить

✅  2019/01/29 16:21, Автор сайта          #21 

Что будет происходить после этого?

На каждый случай типов не напасёшься.

Многие системы обработки исключений смешивают обработку программных ошибок и ошибок входных данных, что некорректно во многих случаях.

try {
    a = add(inputA, inputB);
} catch {
    log("недопустимые входные данные")
}
p = mul(a % 8, inputB /* % 8 ошибка в программе*/);
log(p);

Так сначала нужно понять, что предлагаете Вы и чем оно лучше всего остального.

Почему я?

✅  2019/01/29 16:58, MihalNik          #22 

Суммирование чисел повышает требование к разрядности на 1 бит. Если в цикле делается 1000 сложений, то результат должен храниться в N+1000 разрядах, где N – исходная разрядность операндов.

✅  2019/01/29 18:21, Comdiv          #23 

Функция досрочно завершит свою работу ... возврат делается не в точку вызова, а в точку обработки ошибки.

В таком варианте ошибки подпрограмм и ошибки данных неотделимы

можно переписать Ваш код:

if (add(&a, inputA, inputB)) {
    p = mul(a % 8, inputB /* % 8 ошибка в программе*/);
    log(p);
} else {
    log("недопустимые входные данные")
}

✅  2019/01/29 18:26, Comdiv          #24 

try {
    p = (inputA + inputB) % 8 * (inputB/**/);
    log(p);
} catch {
    log("недопустимые входные данные")
}

✅  2019/01/30 10:33, Автор сайта          #25 

N+10

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

код с обычным способом обработки

Можно переписать, но тогда обработка исключений становится только обузой по сравнению с самым простым подходом

с учётом "многоэтажности", где уже неясно где находится обработчик.

Можете описать поподробней с примером?

учётная запись  ненадёжная импорт учётной записи (...) {
    (   учётная запись . id = читать id ()
        учётная запись . ФИО = читать ФИО ()
        учётная запись . email = читать email ()
        учётная запись . полномочия = читать полномочия ()
     при ошибке
        ошибка = причина (НЕ ПРОШЛА ПРОВЕРКУ)
}
. . .
( моя учётная запись = импорт учётной записи (. . .)
    при ошибке
 Сообщение("ошибка чтения учётной записи"))

✅  2019/02/05 22:14, utkin          #26 

Это моветон. Это инструмент не повседневного, а исключительного использования. Всё по причине тяжеловесности.

Она всегда была и будет обузой, нелюбимым занятием у программистов.

( ...
    m * n + p / q - r
    при ошибке
    // реакция на ошибки в цепочке вычислений
)

✅  2019/02/07 19:01, Автор сайта          #27 

Это по причине того, что Вы обязаны сначала спроектировать программу, прежде чем возьметесь за её написание... Тяжеловесность тут не при чём.

Непонятно почему Вы так решили. Нелюбимым занятием по сравнению с чем?

Деление у нас всегда ненадежная операция... программисты будут тупо забивать и ставить там заглушки?

✅  2019/02/07 19:25, utkin          #28 

На форумах можно встретить немало жалоб на второе, но никак на первое.

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

В этом примере все операции содержат риски выдачи неправильного результата. Но обнаружить ошибку и выдать сообщение о ней — это лучше, чем не обнаружить и выдать неправильный результат под видом правильного. Конечно, могут заниматься формальными отписками, но для добросовестной работы ветвь при «ошибке» — подспорье. И хорошую, и плохую программу можно написать на любом языке программирования. Задача языка программирования — помогать в первом случае и препятствовать во втором.

✅  2019/02/08 16:46, Автор сайта          #29 

Вы ремесленник

✅  2019/02/09 08:21, utkin          #30 

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

Так что да, подтверждаю: проверки обязательны везде просто потому, что существует вероятность нечаянно взорвать ядерный реактор.

Вот примеры из жизни, к чему приводят ошибки в программах.

Кстати, идея об обязательных проверках при риске получить ошибку лучше вписывается в работу конвейера — это ж ОТК в его конце. А Вы возражаете против этого, желаете «творческих» разброда и шатаний.

✅  2019/02/09 15:16, Автор сайта          #31 

Нет, что Вы, операционные системы пишут художники, конечно. Вы серьезно? Вы знаете почему Java один из самых часто используемых? Узнайте.

Ваше решение в цикле — это адские тормоза.

Возьмите факториал

Ваш супербыстрый код будет вызываться каждый раз, когда он НЕ НУЖЕН в алгоритме.

Вы их решить подобным образом НЕ СМОЖЕТЕ.

Есть такая вещь — ПРОГРАММНАЯ ИНЖЕНЕРИЯ.

✅  2019/02/24 00:10, rst256          #32 

y = (tan(x) при ошибке 0)   // ?

y = (tan(pi) при ошибке 0)

✅  2019/02/24 11:00, Автор сайта          #33 

если она [функция] ненадёжная, тогда какого лешего она делает в релизе?

y = (tan(x) при ошибке 0)

В коде, где невозможно появление ошибки в принципе, нужно задать реакцию на ошибку!

там, где программист не пожелал сделать собственную проверку, будет использована встроенная в эту функцию проверка по умолчанию

✅  2019/03/13 15:49, Бурановский дедушка          #34 

✅  2019/03/15 18:20, Автор сайта          #35 

Жаль, конечно, что ошибки Boeing 737 MAX 8 выявляются только fly time.

✅  2019/03/16 19:26, Бурановский дедушка          #36 

✅  2019/03/16 22:53, kt          #37 

✅  2019/03/18 01:08, Автор сайта          #38 

✅  2019/03/20 14:58, rst256          #39 

А какая реакция на ошибку должна быть предусмотрена?

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

✅  2019/03/20 16:13, rst256          #40 

Серия недавних катастроф с новой моделью «Боинга» с очень большой вероятностью связана с ошибками в ПО. Так что тема обработки ошибок поднята правильно. Можно придраться к деталям реализации, но принцип обязательности проверки — это движение в верном направлении.

✅  2019/03/26 16:53, Автор сайта          #41 

• сам никогда не бросай исключений,
• всегда перехватывайте любое возможное исключение, которое может быть вызвано библиотекой, которую я использую, в той же строке, в которой оно выдается, и немедленно устраняйте её.

• Они невидимы в исходном коде. Глядя на блок кода, включая функции, которые могут генерировать или не генерировать исключения, нет никакого способа увидеть, какие исключения могут быть выброшены и откуда. Это означает, что даже тщательная проверка кода не выявляет потенциальных ошибок.
• Они создают слишком много возможных точек выхода для функции. Чтобы написать правильный код, вам действительно нужно продумать каждый возможный маршрут кода в вашей функции. Каждый раз, когда вы вызываете функцию, которая может вызвать исключение и не перехватить его по месту, вы создаете возможности для неожиданных ошибок, вызванных внезапно завершившимися функциями, оставив данные в несогласованном состоянии или других маршрутах выполнения кода, о которых вы не подумали.

T tmp;
if (ERROR == g(x, tmp))
     errorhandling;
if (ERROR == f(tmp, result))
     errorhandling;

✅  2019/03/26 23:07, Автор сайта          #42 

не могу понять, зачем он продолжает писать на Питоне и пытается «кормить лошадь углём и запрягать в паровоз»

Ощущение, что чуваки увидели Rust и поняли, что до этого занимались какой-то фигней :)

Выглядит как попытка затащить монады в язык, который к этому не приспособлен

✅  2019/05/11 08:39, utkin          #43 

х = 5
у = 6
абвгд = х/y

✅  2019/05/11 13:01, Автор сайта          #44 

✅  2019/05/11 19:59, utkin          #45 

а вот третья строка в этой в проверке нуждается.

✅  2019/05/12 16:40, Автор сайта          #46 

✅  2019/05/12 20:08, utkin          #47 

✅  2019/05/14 12:47, Автор сайта          #48 

( x = 5
  y = 6
  z = x/y
  a = get_str()	// ввод значения
  b = get_str()	// функция get_str — не чистая
  c = a/b)

• x и y являются константами,
• операция деления является чистой функцией (вот она, польза явной чистоты функции, поддерживаемой синтаксисом). Поскольку при делении констант x и y (а деление — операция ненадёжная) ошибок не возникло, то z заменяется результатом деления.

((x = 5
    y = 6
    z = x/y
  при ошибке
    put_str("ошибка при делении"))
 ( a = get_str()	// ввод значения
    b = get_str()	// функция get_str — не чистая
    c = a/b
  при ошибке
    put_str("ошибка при делении"))

✅  2019/05/14 16:10, utkin          #49 

Как увидеть, нужна ли проверка? Если на входе чистой функции все константы, то проверка не нужна. А все сомнения — вычислимо на этапе компиляции или нет — развеет компилятор.

✅  2020/02/03 13:14, Неслучайный читатель          #50 

✅  2020/02/03 19:19, MihalNik          #51 

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

✅  2020/02/04 13:26, Неслучайный читатель          #52 

public static int binarySearch(int[] a, int key) {
    int low = 0;
    int high = a.length — 1;

    while (low <= high) {
        int mid = (low + high) / 2;
        int midVal = a[mid];

        if (midVal < key)
            low = mid + 1
        else if (midVal > key)
            high = mid — 1;
        else
            return mid; // key found
    }
    return -(low + 1);  // key not found.
 }

✅  2020/02/05 19:59, Александр Коновалов aka Маздайщик          #53 

✅  2020/10/05 23:19, Неслучайный читатель          #54 

Автор сайта
К чему приводит генерация исключения? К тому, что вызывается «@_ReThrowException$quipuc», которой передаются два нулевых параметра. Т.е. ни установка каких-то флагов, ни установка какого-то значения переменной, ни переход на ветку «catch» — ни один из «дешёвых» вариантов не задействован. Вызывается функция, которая ничего не знает о той ветке «catch», где она будет обрабатываться. Значит, эту ветку функция будет просто искать

В случае выброшенного исключения оверхед составляет в среднем порядка 10000 — 100000 циклов CPU, а в худшем случае может достигать порядка миллисекунд

✅  2022/02/15 18:18, Автор сайта          #55 

Герб Саттер (Herb Sutter) в P709 описал новый механизм передачи исключений. Идейно, функция возвращает std::expected, однако вместо отдельного дискриминатора типа bool, который вместе с выравниванием будет занимать до 8 байт на стеке, этот бит информации передаётся каким-то более быстрым способом, например, в Carry Flag.

Функции, которые не трогают CF (таких большинство), получат возможность использовать статические исключения бесплатно — и в случае обычного возврата, и в случае проброса исключения! Функции, которые вынуждены будут его сохранять и восстанавливать, получат минимальный оверхед, и это всё равно будет быстрее, чем std::expected и любые обычные коды ошибок.

Выглядят статические исключения следующим образом:

int safe_divide(int i, int j) throws(arithmetic_errc) {
    if (j == 0)
        throw arithmetic_errc::divide_by_zero;
    if (i == INT_MIN && j == -1)
        throw arithmetic_errc::integer_divide_overflows;
    return i / j;
}

double foo(double i, double j, double k) throws(arithmetic_errc) {
    return i + safe_divide(j, k);
}

double bar(int i, double j, double k) {
    try {
        cout << foo(i, j, k);
    } catch (erithmetic_errc e) {
        cout << e;
    }
}

✅  2022/03/02 23:11, Неслучайный читатель          #56 

этот бит информации передаётся каким-то более быстрым способом, например, в Carry Flag.

✅  2022/03/03 17:14, Автор сайта          #57 

✅  2022/04/24 15:54, Неслучайный читатель          #58 

Американский крейсер заглох посреди океана из-за деления на «0»

✅  2022/05/24 23:27, Неслучайный читатель          #59 

если она ненадёжная, тогда какого лешего она делает в релизе?

❔  2024/04/28 15:58, Автор сайта          #60 

У неё [архитектуры «Эльбрус»] было ещё одно интересное свойство: в неё была внедрена на тот момент достаточно редкая технология. Сейчас мы её называем технология безопасных вычислений, а тогда это просто называлось «теговая защита», но суть её такая: машина сама контролировала, насколько вы соблюдаете логические правила программирования. Когда вы программируете, вы всегда как-то распределяете память для программы в общем адресном пространстве приложения, и очень частая ошибка, когда вы, распределив память, например, выделив 10 байт под слово какое-то, вы в это место запишете в каком-то месте программы больше, не 10 байт, а, скажем, 20 символов. Что при этом происходит? Вы разрушаете объекты, которые расположены рядом с этим местом в памяти компьютера. И обычные компьютеры, как и сегодня Х86, ARM, этого не замечают. То есть процессор это просто пропускает, он не знает про логику программы, и это приводит к тому, что либо сразу, либо потом возникает отложенная ошибка, то есть программа в какой-то момент падает или ведет себя неправильно просто потому, что её внутренняя структура нарушена. А МВК «Эльбрус-2» и «Эльбрус-1» имели технологию, которая это ловила на аппаратном уровне, то есть скорость отладки, по свидетельству главного конструктора системы противоракетной обороны Москвы Анатолия Басистова, возросла в 25 раз по сравнению с аналогами.

мы заметили, что существенную часть любой ЭВМ составляют схемы контроля, более того, мы видели ситуации, когда ЭВМ не работала именно из-за ошибок в схеме контроля. Отключаешь схему контроля — и всё в порядке! Потом мы заметили, что многие проверки, выполняемые аппаратурой, повторяют аналогичные проверки, которые перед этим делал транслятор с АЯВУ. Поскольку мы разрабатывали и архитектуру ЭВМ, и её системное ПО, мы решили, что подобная избыточность нам не нужна. Мы решили создать ЭВМ, для которой в принципе нельзя составлять программы на ассемблере, тем более, в кодах. Наша технологическая цепочка всегда включает трансляцию с АЯВУ, поэтому то, что проверил транслятор, аппаратура должна принимать «на веру». Зачем нужна проверка на неправильный код операции, неправильный номер регистра или некорректную адресацию, если транслятор такого не генерирует?

Транслятор и операционная система гарантируют, что если на какой-то сегмент памяти есть ссылка (в виде физического адреса) из стека адресов, то этот сегмент не может быть переписан в какое-то другое место в памяти. Поэтому возможна очень эффективная реализация виртуальной памяти. Транслятор может точно подсчитать аппетит каждой процедуры на регистры в стеке, поэтому не нужны аппаратные проверки на переполнение или исчезновение стека. Таких примеров, когда транслятор помогает упростить аппаратуру, нашлось много. Но и хорошо спроектированная аппаратура может облегчить реализацию транслятора. HLL-компьютеры [High-level language computer] содержат не только простые команды «сложить», «вычесть», «перейти», но и такие сложные, как «вызов процедуры», «цикл», «вырезка элемента массива», что упрощает транслятор.

Оказалось, что гарантировать корректную работу аппаратуры мы можем только для статических АЯВУ с полным контролем типов в период компиляции таких, как Алгол 68, Паскаль, Модула 2, Ада, но не таких, как С и PL/1.

Добавить свой отзыв

Написать автору можно на электронную почту
mail(аt)compiler.su