S>Но, как оказалось, народ идеи не понял. Так и вернулись к понятным дебилоидам кодам возврата, т.к. проверяемые исключения осилить не смогли. Так же и в Kotlin их решили не делать.
Я думаю концепция GetLastError()/errno недооценена
Но ее надо чутка расширить, параметром facility.И API сделать таким:

void SetError(FacilityID facility, ErrorObject error);
ErrorObject *GetError(FacilityID facility, bool reset = false);

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

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

Подобные аспектно-ориентированные last-error коды ошибок не имеют ни одной из этих проблем. Я у себя юзал такой подход, очень удобно. Типа пишешь в файл длинную сериализацию чего либо, и в конце просто проверяешь — все ли записи в файл прошли гладко. Удобно.
Для любителей ООП, возможна вариация — вместо глобальной SetError/GetError сделать их методами интерфейс ErrorHolder, который реализуется всеми объектами, которые могут совершить ошибку. И тогда код с сериализацией в файл будет выглядеть так:

FileObject fo("/foo/bar", "w");
fo.WriteString("foo");
fo.WriteString("bar");
fo.WriteInteger(123);
fo.Flush();
if (fo.GetError()) (fo.GetError()->Text);

S>Но, как оказалось, народ идеи не понял. Так и вернулись к понятным дебилоидам кодам возврата, т.к. проверяемые исключения осилить не смогли. Так же и в Kotlin их решили не делать.
Я думаю концепция GetLastError()/errno недооценена
Но ее надо чутка расширить, параметром facility.И API сделать таким:

void SetError(FacilityID facility, ErrorObject error);
ErrorObject *GetError(FacilityID facility, bool reset = false);

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

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

Подобные аспектно-ориентированные last-error коды ошибок не имеют ни одной из этих проблем. Я у себя юзал такой подход, очень удобно. Типа пишешь в файл длинную сериализацию чего либо, и в конце просто проверяешь — все ли записи в файл прошли гладко. Удобно.
Для любителей ООП, возможна вариация — вместо глобальной SetError/GetError сделать их методами интерфейс ErrorHolder, который реализуется всеми объектами, которые могут совершить ошибку. И тогда код с сериализацией в файл будет выглядеть так:

FileObject fo("/foo/bar", "w");
fo.WriteString("foo");
fo.WriteString("bar");
fo.WriteInteger(123);
fo.Flush();
if (fo.GetError()) ShowMessage(fo.GetError()->Text);