"обработка исключений" vs "обработка кодов возврата"

[Qraizer]

Чего?

Добавлено 26.11.24, 17:58
<stacktrace>

[Majestio]

Цитата Qraizer @ 26.11.24, 17:57

Чего?

Я там редактировал, пока ты там читал! =) Перечитай есчо раз =)

[Qraizer]

Я правильно прочитал. Ты предлагаешь мне схавать аппаратное исключение? Это оффтоп темы

[Majestio]

Цитата Qraizer @ 26.11.24, 19:08

Я правильно прочитал. Ты предлагаешь мне схавать аппаратное исключение? Это оффтоп темы

А ты что, в сказку попал?!!

1) Есть сетевые ошибки, масса
2) Есть ошибки устройств I/O, часто
3) Крайний случай - тупо ошибки RAM, нечасто но видели

Я тебе предлагаю это схавать! =)

[Qraizer]

Majestio, не рекомендую троллить или подменять термины. Можешь, конечно, подумать на предмет

LONG WINAPI translateException(EXCEPTION_POINTERS *excPtr)
{
  const unsigned EH_EXCEPTION_NUMBER = ('msc' | 0xE0000000);    // <- undocumented
 
  if (excPtr->ExceptionRecord->ExceptionCode == EH_EXCEPTION_NUMBER)
    return EXCEPTION_CONTINUE_SEARCH;
  throw StackTrace(excPtr->ExceptionRecord->ExceptionCode);     // dangerously
}
 
// нуль
int b = 0;
 
int g()
{
  return 123 / b;       // деление на нуль
}
 
int f()
{
  return g();
}
 
int main()
{
  HANDLE hExc = AddVectoredExceptionHandler(1, translateException);
 
  if (hExc == NULL)
    return std::cout << "AddVectoredExceptionHandler() fails: " << GetLastError() << std::endl,
           1;
 
  Guard excRem([=](){ RemoveVectoredExceptionHandler(hExc); });
 
  try
  {
    f();
  }
  catch(const StackTrace& exc)
  {
    std::clog << std::hex << exc.why() << "\nStack trace -->:\n" << exc.getStack();
    return 2;
  }
  return 0;
}

но это не имеет никакого отношения ни к

Цитата Majestio @ 26.11.24, 19:50

1) Есть сетевые ошибки, масса
2) Есть ошибки устройств I/O, часто
3) Крайний случай - тупо ошибки RAM, нечасто но видели

ни к теме C++EH

[Majestio]

Цитата Qraizer @ 26.11.24, 20:40

Majestio, не рекомендую троллить или подменять термины.

И в помыслах не было! Просто я немножко на позитиве в следствие принятия соответствующих, скажем так, пищевых добавок

Цитата Qraizer @ 26.11.24, 19:08

Ты предлагаешь мне схавать аппаратное исключение?

Желаю уточнить. Мы сейчас говорим о юзер-спэйсе. И все что может быть "выкинуто" аппаратурой - мы не ловим напрямую, а ждем реакции исключительно операционной системы. Работу проги в режиме ядра операционной системы, или тем паче, вообще без операционной системы - мы щяс не рассматриваем. Поэтому да - сетевые ошибки, и ошибки I/O могут уверенно прилетать в юзерспейс, уже тёплые, ламповые, готовые. И там (в юзерспейсе) они могут и должны обрабатываться. Что касается аппаратных ошибок RAM - тут согласен. Эту "беду" на прикладном уровне очень сложно, а чаще и невозможно, победить.

Цитата Qraizer @ 26.11.24, 20:40

WINAPI

А вот тут ты очень обидно сказал!!! Тем самым проигнорировал линуксоидов, бисидишников и большое количество mac-пролетариев!

И кстати тут:

Цитата Qraizer @ 26.11.24, 20:40

int g()
{
  return 123 / b;       // деление на нуль
}

В рамках программирования "здорового человека" нужно немного поправить сигнатуру функции. А именно проверять b на нуль. И принимать одно из решений, учитывая тему топика: 1) Выкидывать свое исключение, оставив сигнатуру функции как есть 2) Либо поступить как поступают в других ЯП типа Rust/Dart - возвращать не int, а Result. Который, для упрощения, есть структура с полями "валидное_значение?" и "значение". Ну если не структура, пусть будет std::tuple. Не важно, главное принцип - "видишь деление, проверь". Тоже самое касается и остальных мест, где могут быть проблемсы.

[Qraizer]

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

std::optional<int> g()
{
  return b == 0 ? decltype(g())() : 123 / b;       // деление на нуль
}
 
int f()
{
  return g().value();
}

g() учитывает возможный сбой, f() не учитывает и бросит std::bad_optional_access. Или:

std::variant<int, std::error_code> g()
{
  using retType = decltype(g());
  return b == 0 ? retType(std::make_error_code(std::errc::invalid_argument)) : retType(123 / b);       // деление на нуль
}
 
int f()
{
  return std::get<int>(g());
}

Бросит std::bad_variant_access. Но вопрос остаётся: ты от меня хотел, чтобы я просто повторил ранее сказанное?
Если же мы говорим от аппаратных отказах, то Стандартного способа преобразовать исключения низкого уровня в C++EH не существует и вряд ли когда-нибудь будет существовать. В WINAPI испокон веков существовал SEH (даже в Win16, хоть и в очень зачаточном виде). Это часть API, и это позволяет работать с ними единообразным образом на любых уровнях. Даже в ядре. (Даже C++EH в ядре.) Однако WINAPI поддерживает не только C++, поэтому возлагать на ОС прям вот C++EH шоколадно. Однако несложно реализовать трансляцию SEH в C++EH. Выше корявый, но пример. Что до ваших никсов, то это ваши сложности. У вас есть сигналы, вот с ними и ...думайте. Мне влом, не хватало ещё какой-нить в STM32 под realtime tiny os переносить его десяток исключений с парой десятков их источников.

[Majestio]

Цитата Qraizer @ 27.11.24, 14:29

Ты всё-таки определись, что ты хочешь.

А я уже определился! Только одно прошу - давай ты без нервов, давай без них самих! =)

В процессе обсуждения вопроса мы выявили два "важных" момента:

1) Обеспечение транзакционной целостности объектов - тут понятно и просто
2) Выброс стека вызовов при ловле исключений - тут (лично для меня пока не просто)

Я все "почитаю и изучу". Ток одна просьба. Qraizer, не поднимай ни себе и не остальным нервы. Мы тут все более-менее на равных. Кто-то более компетентен, кто менее. Но в этом суть и соль общения. Очень тебя прошу, ты же профи. Держи себя в рамках, даже если к тебе обращаются специалисты гораздо низшего относительно тебя уровня!

Добавлено 29.11.24, 11:55
Qraizer, да, кстати, да ... "Деление на нуль" - наверное одно, и наверное, единственное исключение, которое можно обозвать "аппаратным". Или не? Какие еще подобные исключения можно словить в "юзер-спейсе", которые не обрабатывала операционная система, а просто "вбросила"? И это не просто стёб, и не censored. Тут дело разработок. Просто скажи - вот они (список), или скажи "я погорячился". Прощу меня понять - мне важна суть, а не прав ты или не прав. Вообще на второе забей! Я триста раз могу ошибаться, но я тут чтобы получать достоверную инфу. Без обид!

Сообщение отредактировано: Qraizer - 30.11.24, 16:10

[macomics]

#AC и #BOUND (последнее давно не используется)

[D_KEY]

В плане дизайна обработки ошибок я бы сейчас рекомендовал использовать std::optional (иногда std::variant) и новенький std::expected.
Ну и именно исключения оставить на тот случай, когда совсем никак без них не обойтись (см. первое сообщение Qraizerа)

А самое главное не забывать про т.н. гарантии безопасности исключений, введенные Саттером (или возможно Абрахамсом, но лично я впервые прочел у Саттера).
Ну базовая, строгая и гарантия отсутствия исключений. Это достаточно легко гуглится, не вижу смысла тут писать подробности.
Без понимания этих принципов будет очень сложно (невозможно?) написать качественный код с использованием исключений.

Сообщение отредактировано: D_KEY - 30.11.24, 14:06

[Qraizer]

Цитата D_KEY @ 30.11.24, 14:02

Без понимания этих принципов будет очень сложно (невозможно?) написать качественный код с использованием исключений.

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

[Qraizer]

Majestio, если заглянуть в winnt.h, то там их вагон и маленькая тележка, штук 60. Не все они аппаратные, но все низкоуровневые. Типа STATUS_GUARD_PAGE_VIOLATION, STATUS_BREAKPOINT, STATUS_STACK_OVERFLOW итп. Конкретно аппаратных немного:

Код исключения	Причина исключения
STATUS_ACCESS_VIOLATION	Чтение или запись в недоступный адрес в памяти.
STATUS_BREAKPOINT	Обнаружение аппаратной точки останова; используется только в отладчиках.
STATUS_DATATYPE_MISALIGNMENT	Чтение и запись в данные по адресу с неверным выравниванием. Например, 16-разрядные записи должны выравниваться относительно машинных слов с границей 2 байта. (Неприменимо к процессорам Intel 80x86.)
STATUS_FLOAT_DIVIDE_BY_ZERO	Деление значения с плавающей запятой на 0,0.
STATUS_FLOAT_OVERFLOW	Превышение максимальной положительной экспоненты с плавающей запятой.
STATUS_FLOAT_UNDERFLOW	Превышение модуля наименьшей отрицательной экспоненты с плавающей запятой.
STATUS_FLOATING_RESEVERED_OPERAND	Использование зарезервированного формата с плавающей запятой (недопустимое использование формата).
STATUS_ILLEGAL_INSTRUCTION	Попытка выполнить код инструкции, не определенной процессором.
STATUS_PRIVILEGED_INSTRUCTION	Выполнение инструкции, которая не разрешена в текущем режиме машины.
STATUS_INTEGER_DIVIDE_BY_ZERO	Деление значения целочисленного типа на 0.
STATUS_INTEGER_OVERFLOW	Попытка выполнения операции, которая превышает диапазон целочисленного типа.
STATUS_SINGLE_STEP	Выполнение одной инструкции в пошаговом режиме; используется только в отладчиках.

Но тут встаёт вопрос: а можно ли их считать отдельно от вон того списка из 60 элементов?

[Qraizer]

P.S. У x86/64 исключений больше.
Table 5-1. Protected-Mode Exceptions and Interrupts

Vector No.	Mne-monic	Description	Type	Error Code	Source
0	#DE	Divide Error	Fault	No	DIV and IDIV instructions.
1	#DB	RESERVED	Fault/ Trap	No	For Intel use only.
2	—	NMI Interrupt	Interrupt	No	Nonmaskable external interrupt.
3	#BP	Breakpoint	Trap	No	INT 3 instruction.
4	#OF	Overflow	Trap	No	INTO instruction.
5	#BR	BOUND Range Exceeded	Fault	No	BOUND instruction.
6	#UD	Invalid Opcode (Undefined Opcode)	Fault	No	UD2 instruction or reserved opcode.1)
7	#NM	Device Not Available (No Math Coprocessor)	Fault	No	Floating-point or WAIT/FWAIT instruction.
8	#DF	Double Fault	Abort	Yes (zero)	Any instruction that can generate an exception, an NMI, or an INTR.
9	Coprocessor Segment Overrun (reserved)	Fault	No	Floating-point instruction.2)
10	#TS	Invalid TSS	Fault	Yes	Task switch or TSS access.
11	#NP	Segment Not Present	Fault	Yes	Loading segment registers or accessing system segments.
12	#SS	Stack-Segment Fault	Fault	Yes	Stack operations and SS register loads.
13	#GP	General Protection	Fault	Yes	Any memory reference and other protection checks.
14	#PF	Page Fault	Fault	Yes	Any memory reference.
15	—	(Intel reserved. Do not use.)	No
16	#MF	x87 FPU Floating-Point Error (Math Fault)	Fault	No	x87 FPU floating-point or WAIT/FWAIT instruction.
17	#AC	Alignment Check	Fault	Yes (Zero)	Any data reference in memory.3)
18	#MC	Machine Check	Abort	No	Error codes (if any) and source are model dependent.4)
19	#XM	SIMD Floating-Point Exception	Fault	No	SSE/SSE2/SSE3 floating-point instructions5)
20-31	—	Intel reserved. Do not use.

Как к ним относится WINAPI, беспонятия, не интересовался.

---

¹⁾ The UD2 instruction was introduced in the Pentium Pro processor.
²⁾ Processors after the Intel386 processor do not generate this exception.
³⁾ This exception was introduced in the Intel486 processor.
⁴⁾ This exception was introduced in the Pentium processor and enhanced in the P6 family processors.
⁵⁾ This exception was introduced in the Pentium III processor.

[macomics]

Цитата Qraizer @ 30.11.24, 14:25

STATUS_FLOAT_DIVIDE_BY_ZERO Деление значения с плавающей запятой на 0,0.
STATUS_FLOAT_OVERFLOW Превышение максимальной положительной экспоненты с плавающей запятой.
STATUS_FLOAT_UNDERFLOW Превышение модуля наименьшей отрицательной экспоненты с плавающей запятой.
STATUS_FLOATING_RESEVERED_OPERAND Использование зарезервированного формата с плавающей запятой (недопустимое использование формата).

Вот эти 4 это просто флаги в fpu.StatusWord и как реальные Exception они не генерируются. Т.е. они софтверные и выбрасываются после проверки флага в регистре после fpu инструкции.

[Majestio]

Цитата Qraizer @ 30.11.24, 14:25

Majestio, если заглянуть в winnt.h, то там их вагон и маленькая тележка, штук 60. Не все они аппаратные, но все низкоуровневые. Типа STATUS_GUARD_PAGE_VIOLATION, STATUS_BREAKPOINT, STATUS_STACK_OVERFLOW итп. Конкретно аппаратных немного:

Ну, положим, проверку деления на нуль можно делать, и нужно ... Но где и как делать проверку остального, к примеру STATUS_ILLEGAL_INSTRUCTION. Я даже не знаю - смогу ли я такое сгенерировать специально! Ну может быть какими-то ассемблерными вставками ... и то, не уверен.