Пользователи и не платят по 140$. Как Вы справедливо заметили большинство не платит вообще нисколько.
Платят компании желающие что-либо этим пользователям впарить. И в контексте нашей поставленной с ног на голову экономики 140$ на пользователя — это очень, ооочень пессимистичная оценка.
Блин, эту энерию бы да в мирное русло.
Почему вместо построения удобных тулов для анализа логов пишут очередные копалки для стека? Почему в 21 веке самым удобным тулом для отладки остаётся less?
Ну нет в стэках всей информации, которая нужна при отладке, или есть но требуется 9000 кликов чтобы её извлечь. Да и подключаться дебагером не всегда можно и не всегда удобно.
Он должен находиться не «где-то» а прямо тут. Потому-что прямо тут можно забыть закрыть открытый коннект к БД или обратиться к неинициализированной переменной с вываливанием другого исключения, превращающего поиск источника ошибки в детективный роман.
Исключение описывает проблему тем, кто спрашивает. А тех кто не спрашивает закатывает в асфальт. Просачивание не позволяет определить место для обработки ошибки, оно позволяет только перебрасывать наверх в надежде, что кто-нибудь таки знает что делать.
Использование исключений упирается в талант и прозорливость архитектора системы. Они даже в теории ограничены ограничены. А на практике обычно архитектора вообще нет.
Клиенту больше не надо анализировать сложный результат, он попросил найти текст — ему нашли; если нет — он об этом даже не узнает.
Конечно, анализировать ошибки это для неудачников. У реальных пацанов всё всегда OK… ну если не OK то по крайней мере хватает стали в яйцах сказать пользователю, что OK.
Например в Java компилятор может проверить, что произведён перехват с помощью catch, но не может проверить, его корректность или наличие корректного finally. В С# ситуация такая же AFAIK.
На самом деле у вас терминология более-менее вменяема, в отличии от автора.
То есть «неблокирующие» и «без ожиданий» — это синонимы в великом и могучем?
Мне кажется или «независящее от других потоков» не гарантируется для wait-free? (вот та-жа STM-транзакция не блокирует, но время на выполнение явно зависит от других потоков).
Есть два устоявшихся термина:
lock-free — это алгоритм, который гарантированно не ведёт к deadlock.
wait-free — это алгоритм, не требующий ни от одного потока простоя в ожидании ресурса.
Изобретение своих словянофильских терминов ничего кроме бардака и проблем с поиском не приносит. В частности из вашего коментария (по сслыке) я понял, что ресь идёт о wait-free алгоритме. Разбираться в том где у вас косяк: в объяснении или в голове мне лень, думаю любому здравомыслящему человеку тоже.
Платят компании желающие что-либо этим пользователям впарить. И в контексте нашей поставленной с ног на голову экономики 140$ на пользователя — это очень, ооочень пессимистичная оценка.
Почему вместо построения удобных тулов для анализа логов пишут очередные копалки для стека? Почему в 21 веке самым удобным тулом для отладки остаётся less?
Ну нет в стэках всей информации, которая нужна при отладке, или есть но требуется 9000 кликов чтобы её извлечь. Да и подключаться дебагером не всегда можно и не всегда удобно.
Цель конструкции
} catch (Exception e) {
throw new Exception(e);
}
непонятна.
Исключение описывает проблему тем, кто спрашивает. А тех кто не спрашивает закатывает в асфальт. Просачивание не позволяет определить место для обработки ошибки, оно позволяет только перебрасывать наверх в надежде, что кто-нибудь таки знает что делать.
Использование исключений упирается в талант и прозорливость архитектора системы. Они даже в теории ограничены ограничены. А на практике обычно архитектора вообще нет.
Конечно, анализировать ошибки это для неудачников. У реальных пацанов всё всегда OK… ну если не OK то по крайней мере хватает стали в яйцах сказать пользователю, что OK.
Например в Java компилятор может проверить, что произведён перехват с помощью catch, но не может проверить, его корректность или наличие корректного finally. В С# ситуация такая же AFAIK.
То есть «неблокирующие» и «без ожиданий» — это синонимы в великом и могучем?
Мне кажется или «независящее от других потоков» не гарантируется для wait-free? (вот та-жа STM-транзакция не блокирует, но время на выполнение явно зависит от других потоков).
lock-free — это алгоритм, который гарантированно не ведёт к deadlock.
wait-free — это алгоритм, не требующий ни от одного потока простоя в ожидании ресурса.
Изобретение своих словянофильских терминов ничего кроме бардака и проблем с поиском не приносит. В частности из вашего коментария (по сслыке) я понял, что ресь идёт о wait-free алгоритме. Разбираться в том где у вас косяк: в объяснении или в голове мне лень, думаю любому здравомыслящему человеку тоже.