Тихо ночью, из груши ,
В друг раздался крик
"ДУШИИИИИ".
Мы немного огляделись
Шеи нет и слава богу,
Хоть не складно получилось,
но мы дальше покатились...
G> Смотря что такое cleanup? G> Если простая подчистка ресурсов так используйте смарт-поинтеры, классы-стражи, функторы и тп, G> которые в деструкторе все сделают. ( Их можно передавать и темплейтным параметром) G> Если это какой-то частный роллбэк только и только в случаях ошибки, я бы не стал это G> запихивать в темплейтную функцию и пересмотрел бы дизайн решения. G> Можно и в этом случае кстати попробовать предать какой-то функтор.
Согласен. Но в некоторых случаях сложность стражей превосходит сложность такого решения.
Чуть ниже Alexey Shirshov привел хороший пример.
G> Самое плохое в единичном catch (...) — это глотание ошибки.
Все, что я говорил, относилось к нейтральных по отношению к исключениям функциям
Т.е. throw обязателен.
G> а)Глотать _свои_ ошибки с моей точки зрения очень и очень плохо. G> Я там видел в ветке народ предлагает для релиза ставить catch(...), так вот пусть G> лучше она упадет и создаст Dr.Watson log. чем G> выдаст "Unknown error" и тем самым похоронит что там за ошибка была и почему.
Для меня наиболее симпатичный вариант таков:
catch (...) на верхнем уровне приложения в котором создается дамп и выдается окошко с возможностью отослать лог + дамп
разработчикам. При этом скрываются детали ошибки (их все же можно посмотреть клацнув по кнопочке), которые большинству пользователей
не нужны и только добавят паники. Опытные пользователи при необходимости их смогут увидеть.
Вобщем почти всё так же, как по умолчанию (WinXP) .
Только окошко свое (пользователь будет думать "они контролируют ситуацию"), создание дампа не зависит от установленного в системе
отладчика и его настроек, возможность одним щелчком отправить багу разработчику да еще и в установленном разработчиком формате.
А вот научить пользователя отправлять лог и дамп в стандартном случае не так-то просто
Ветка "Крик души" затеяна мною...
> Надоело и непробиваемое молчание, весьма типичное для компаний вроде > Aelita, демонстрируемое в ответ на выполненные тестовые по 2-м > позициям.
Думаю, что стоит вычеркнуть сию компанию из сего перечня.
Не зря оставил свой e-mail — связались, попросили уточнить, когда и что было послано.
Позвонили, объяснили, что мое выполнение тестового их не устроило.
А в связи с уходом менеджера немного протянули с ответом.
При этом все в предельно вежливой форме.
Побольше бы компаний действительно заботящихся о собственной репутации.
С уважением, всё тот же:
-Сергей. traffic81@inbox.ru
>> Надоело и непробиваемое молчание, весьма типичное для компаний вроде >> Aelita, демонстрируемое в ответ на выполненные тестовые по 2-м >> позициям. tsR>Думаю, что стоит вычеркнуть сию компанию из сего перечня.
Думаю следует внести ресурс рсдн ру в число иснструментов оказывающих влияние на ай-ти рынок.
Что касается аэлиты, то я года два назад что то им делал ответа тоже не получил
(правда мне и не нужно было)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Андрей Галюзин, Вы писали:
АГ>Для меня наиболее симпатичный вариант таков: АГ>catch (...) на верхнем уровне приложения в котором создается дамп и выдается окошко с возможностью отослать лог + дамп АГ>разработчикам.
Ну так для этого есть SetUnhandledExceptionFilter. Все очень просто и мило.
d> Думаю следует внести ресурс рсдн ру в число иснструментов оказывающих d> влияние на ай-ти рынок. d> Что касается аэлиты, то я года два назад что то им делал ответа тоже d> не получил d> (правда мне и не нужно было)
С учетом того, что русский ит-рынок всего-то в 3-5 городах сосредоточен? Будь сие не так, было бы странно.
Как там... "Спасение утопающий, дело рук самих утопающих"...
Может начать создавать профсоюзы?
Здравствуйте, GUID, Вы писали:
GUI>Здравствуйте, Аноним, Вы писали:
GUI>У меня нет, к сожалению, рецензии именно Вашего тестового задания (речь идет о этом задании), но, для иллюстрации, я приведу два примера (успешный и не успешный) рецензий тестовых заданий месячной давности, чтобы показать, что во-первых, задания анализируются, во-вторых, что одного только факта исполнения кандидатом тестового задания недостаточно — еще важно КАК он его сделал:
GUI>Пример 1 (отрицательный).
GUI>Плюсы: GUI>
GUI>- юный возраст GUI>- использование компонентов .NET (такое тестовое задание данному рецензенту попалось впервые); GUI>
GUI>Минусы: GUI>
GUI> — предыдущий опыт работы был связан скорее с администрированием, нежели с кодированием; GUI> — "знаком с языком VC" — этого может оказаться недостаточно; GUI> — задание выполнено как "отписка", без цели показать "все, на что способен", а с целью сделать "чтобы отстали" GUI> — совершенно неудобный UI (пользователь должен знать имена сервисов и имена машин, чтобы запустить или остановить сервис); GUI> — многократное создание одних и тех же объектов (в VB при каждом нажатии на кнопку создается COM-объект MyServControl; в VC тоже самое происходит с объектом ServiceController); GUI> — catch(...) — за это у нас "расстреливают"; GUI> — глобальные директивы using — это, по крайней мере, плохой стиль программирования. Кроме того, раз уж написал GUI>
? GUI>
GUI>В общем, решили не приглашать.
GUI>Пример 2 (положительный)
GUI>Плюсы
GUI>
GUI>- человек явно стремится показать свои знания (проект выглядит крупнее и "продвинутее" среднестатистического тестового задания); GUI> — не часто встречается в заданиях запуск и останов зависимых сервисов; GUI> — использование обертки для SC_HANDLE; GUI> — использование WNetAddConnection (очень редко встречается в заданиях); GUI> — использование коллекций VB. GUI>
GUI>Минусы:
GUI>
GUI> — в коде не выбрасывается ни одно исключение, но встречается огромное количество конструкций
GUI>
GUI> try {}
GUI> catch(...) {}
GUI>
GUI> — обработка ошибок сделана на возвращаемых значениях (в качестве типа ошибки используется свой собственный enum); GUI> — использование таких конструкций как GUI> using CConnectionImpl::OpenConnection; (см. класс CManagerImpl) конечно говорит о том, что человек знает о их существовании, но на практике означает просчеты в проектировании (в проекте такого масштаба они явно не уместны!); GUI> — встречаются "сишные" функции; используется CString вместо std::basic_string<> (стоит ли прикручивать целый MFC ради этого?); GUI> — доступ к внутреннему представлению вектора (см., например, ServiceCtrl::QueryServiceConfig()); GUI> — std::vector<LPCTSTR> a_Array(a_Size); — выглядит пугающе (это отмечает в комментариях и сам автор); GUI> — функция CManagerImpl::WaitForServiceState() содержит конструкцию
GUI>
GUI>и вызывается в основном потоке (фактически, прямо в обработчике сообщений от UI); как следствие, приложение "зависает", пока не запустится (не остановится) соответствующий сервис (может, это как-то реализовано в VB?). GUI>
GUI>Мнение рецензента: "Не знаю как на ведущего, а на простого "программиста второго уровня" вполне тянет".
GUI>Кандидата пригласили на собеседование.
Пожалуйста, уберите из Вашего задания "Оттестированность программы не имеет значения, главное — продемонстрировать ее функциональные возможности". Т.к. первого кандидата Вы завалили именно на этом. Программа функционирует, по Вашему заявлению Вам это и надо.
А почему расстриливать за Catch()? По-моему, если человек ловит исключения — это хорошо...
По поводу неудобства UI: это ведь тестовое задание, не коммерческая программа. Я бы лучше расстрелял за Sleep(a_Wait); А если сервис "подвиснет" во время остановки? Такое с AVP случается. Что тогда? По-моему, в этом второй кандидат продемонстрировал вопиющее незнание мультитредингово программирования.
По поводу MFC: глупо не использовать стандартные библиотеки, которые идут с языком. Особенно в тестовом задании. Откуда кандидату знать, используете Вы MFC в проектах или нет?
Аноним, если тебя одна контора послала — не расстраивайся. Проверка тестового задания — процесс, на который сильно влияет человеческий фактор. Набирай квалификацию на удаленных проектах. Что тут плохого? По-моему — одно: при иммиграции за границу как Skilled Professional надо подтвердить стаж. а при удаленных проектах это может быть затруднительно.
class FailLogger:
IDisposable
{
public FailLogger(string message)
{
}
string message;
public bool IsOk = false;
public void Dispose
{
if (IsOk)
Trace.WriteLine(message);
}
}
Тогда по месту у тебя будет:
void foo()
{
using (FailLogger log = new FailLogger("Не сделалось то-то и то-то"))
{
do_work();
log.IsOk = true;
}
}
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Теряешь квалификацию!
AS>
AS>publicbool IsOk = false;
AS>
AS>Выделеные фрагменты нужно убрать.
Это ты про то, что в C++ так нельзя писать?
ps
Понимаешь в чем проблема, я умею писать на порядка 30 языков, сейчас активно использую где-то в районе 5-ти языков, если я буду для каждого языка помнить все тонкости синтаксиса, то место в голове у меня кончится.
хъ
DG>ps DG>Понимаешь в чем проблема, я умею писать на порядка 30 языков, сейчас активно использую где-то в районе 5-ти языков, если я буду для каждого языка помнить все тонкости синтаксиса, то место в голове у меня кончится.
Здравствуйте, JohnDoe, Вы писали:
JD>Здравствуйте, Андрей Галюзин, Вы писали:
АГ>>Для меня наиболее симпатичный вариант таков: АГ>>catch (...) на верхнем уровне приложения в котором создается дамп и выдается окошко с возможностью отослать лог + дамп АГ>>разработчикам.
JD>Ну так для этого есть SetUnhandledExceptionFilter. Все очень просто и мило.
Ну не так уж и просто... Пробовал после него вывести тривиальный MessageBox и затем сравнить текущий ExFilter с установленным тобою?