Очень простое правило, при использовании исключений: если можно проверить успешность операции до начала операции исключение использовать не стоит. В большенстве таких случаев это т.н. «костыли». Падени БД, файловой системы, обрыв связи — вот исключительные ситуации. Всё остальное — ошибки. Либо программистов либо пользователей. Соответсвенно — ассерты или обюработка ошибок.
Согласен полностью. Программист — это не леший в заколдованном лесу :) Это проводник, который знает как пройти через лес и выйти с карзиной грибов. :)))
Если разбить эту задачу на мелкие задачи типа «ежу понятно как» то да, сложности нет. Так ведь это и есть работа хрошего программиста. Это просто пример проекта. И сложный момент здесь может быть формула, кототрая должна показывать рейтинг даже если, например, один из источников данных для конкретного домена не доступен. Например alexa не даёт результатов для mymegaporn.kz, а домен на самом деле ценный, и это нужно увидеть. Я не смогу раскрыть здесь все детали проекта.
например, дан список доменных имен, нужно определить их ценность с точки зрения покупки\перепродажи. Учитываются различные факторы, такие как выпадение из истории (weyback records), alexa rank, Google PR и пр. Эти данные нужно собирать из различных источников, учитывая ограничения и нюансы API, либо парсить страницы напрямую.
Кроме знаний, по-моему, хороший программист должен обладать абстрактым мышлением и не думать ограничениями. Знания можно получить, а вот способность «мыслить кодом» это что-то сокральное.
«блог сделать» можно по одному из туториалов, которых полно в интернете. Проекты компании немног другие, именно нетривиальные. Так что мы НЕ ищем людей для создания сайтов-блогов.
а если я предложу по каждому пункту код, не исопльзующий исключения и не уступающий по всем параметрам и даже превосходящий? Откажетесь ли от старой схемы в пользу «безисключенческой»?
в том-то и дело, что я счетаю что «логичские ошибки» не слудует смешивать с системными ошибками. тогда будет толк от обработки последних, вернее тогда будет понятно, что есть ошибка и что нужно с ней делать. Если везде используются исключения, смысл которых зависит от контекста использования — это повышает сложность программы, затрудняет отладку и чтение кода, ухудшает стабильность, и в совокупности ухудшает качество ПО.
знаете, телнет был задуман как нечто гораздо большее, и тот, кто это знает, использует его не только для проверки доступности smtp серверов ;)
я не хочу обсуждать телнет в этом топике с вашего позволения
если исключения используются как хак, а не по прямому назначению, программисту (который «не в теме») понадобиться много времени, чтобы понять, что вообще происходит. ну и отладка такого кода, извините, гемор в чистом виде. так что производительность программистов страдает ещё больше чем проивзодительность кода.
не кернел, но да, паник :) исключения они это и есть. когда участок кода выбрасывает исключение, он как бы говорит «случилось что-то страшное, я не знаю что делать дальше». это как были задуманы эксепшны. если кто-то знает, что делать — пишеться «catch». но таких случаев в реальном приложении не так много — обработка транзакций, чтение из фаловой системы и т.п.
то, что делаете вы (Логика#1-#5 и Ошибки #1-2) — это попытки реализовать систему, основанную на сигналах\сокетах, как например это сделано в десктоп-приложениях. («намёки» на это есть и в .NET, так что возможно это заблуждения идёт «оттудава» )
я пока не склонен «разбивать в пух и прах» такой подход, так как хочу присмотреться поближе. Однако критические изъяны налицо: деградация производительности и уменьшение стабильности системы засчёт неправильной обработки ошибок.
я не хочу обсуждать телнет в этом топике с вашего позволения
try {
doCriticalAction()
} catch (Exception e) {
recoverData();
throw new Exception('Critical action failed');
}
то, что делаете вы (Логика#1-#5 и Ошибки #1-2) — это попытки реализовать систему, основанную на сигналах\сокетах, как например это сделано в десктоп-приложениях. («намёки» на это есть и в .NET, так что возможно это заблуждения идёт «оттудава» )
я пока не склонен «разбивать в пух и прах» такой подход, так как хочу присмотреться поближе. Однако критические изъяны налицо: деградация производительности и уменьшение стабильности системы засчёт неправильной обработки ошибок.