Здравствуйте, Shmj, Вы писали:

S>Но, как оказалось, народ идеи не понял. Так и вернулись к понятным дебилоидам кодам возврата, т.к. проверяемые исключения осилить не смогли. Так же и в Kotlin их решили не делать.

Дебилоиды это те, кто не понимает, что каждому инструменту своё применение.

try
{
   const data = LoadData();
   const processedData = ProcessData(data);
   SaveData(processedData);
}
catch
{
    log.Error("Всё пропало");
}

Допустим, ProcessData() это дорогая операция (рендер на 12 часов для десктопной программы или облачные вычисления за 1000$ для серверной). А при попытке SaveData() происходит облом. Если это серверная программа, то база не соединяется, а если десктопная, то файловая операция не проходит. В этом случае надо вернуть код ошибки, чтобы алгоритм можно было переписать так (серверная программа):

while (tryCount++ < 10 && NotOkay == SaveData(processedData))
{
    await ThisFrameworkSleep(1000);
}

Или так (десктопная):

while (Yes == AskUser("Попытаться обратно?") && NotOkay == SaveData(processedData));

А если за каким-то хером внутри SaveData() оказывается, что processedData внезапно null или InvalidObject, то тогда у нас ИСКЛЮЧИТЕЛЬНАЯ ситуация. Весь алгоритм уже пошёл по звезде, и проверять результат бесполезно. В такой исключительной ситуации нужно выбрасывать исключение. Поэтому они и называются исключениями.

Единственная причина полностью отказаться от исключений — технические соображения. Лично я считаю, что в отсутствие виртуальной машины вреда от исключений больше, чем пользы. Хотя бы потому, что если у нас unmanaged OS и проект состоит из разных модулей, написанных на разных языках с разными стандартными классами исключений, их заколебёшься приводить к одному знаменателю. Да и нахрен не всралось исключение, если неперехваченное оно не даёт при желании хромать дальше с восьмой цифры (как бывает без ВМ).

Но поскольку дебилоидов слишком много, то и общаются они на уровне "а давайте всегда выкидывать исключения ДЛЯ КОНСИСТЕНТНОСТИ". Жопу бы им начать вытирать зубной щёткой. Для консистентности.

Здравствуйте, Shmj, Вы писали:

S>Но, как оказалось, народ идеи не понял. Так и вернулись к понятным дебилоидам кодам возврата, т.к. проверяемые исключения осилить не смогли. Так же и в Kotlin их решили не делать.

Дебилоиды это те, кто не понимает, что каждому инструменту своё применение.

try
{
   const data = LoadData();
   const processedData = ProcessData(data);
   SaveData(processedData);
}
catch
{
    log.Error("Всё пропало");
}

Допустим, ProcessData() это дорогая операция (рендер на 12 часов для десктопной программы или облачные вычисления за 1000$ для серверной). А при попытке SaveData() происходит облом. Если это серверная программа, то база не соединяется, а если десктопная, то файловая операция не проходит. В этом случае надо вернуть код ошибки, чтобы алгоритм можно было переписать так (серверная программа):

while (tryCount++ < 10 && NotOkay == SaveData(processedData))
{
    await ThisFrameworkSleep(1000);
}

Или так (десктопная):

while (NotOkay == SaveData(processedData) && Yes == AskUser("Попытаться обратно?"));

А если за каким-то хером внутри SaveData() оказывается, что processedData внезапно null или InvalidObject, то тогда у нас ИСКЛЮЧИТЕЛЬНАЯ ситуация. Весь алгоритм уже пошёл по звезде, и проверять результат бесполезно. В такой исключительной ситуации нужно выбрасывать исключение. Поэтому они и называются исключениями.

Единственная причина полностью отказаться от исключений — технические соображения. Лично я считаю, что в отсутствие виртуальной машины вреда от исключений больше, чем пользы. Хотя бы потому, что если у нас unmanaged OS и проект состоит из разных модулей, написанных на разных языках с разными стандартными классами исключений, их заколебёшься приводить к одному знаменателю. Да и нахрен не всралось исключение, если неперехваченное оно не даёт при желании хромать дальше с восьмой цифры (как бывает без ВМ).

Но поскольку дебилоидов слишком много, то и общаются они на уровне "а давайте всегда выкидывать исключения ДЛЯ КОНСИСТЕНТНОСТИ". Жопу бы им начать вытирать зубной щёткой. Для консистентности.