Thread: Наша жизнь/по поводу майкрософт и его методов

по поводу майкрософт и его методов
прикол недавно обнаружил, может всем известный конечно

посмотрел в соурс сообщения об ошибке от resin и увидел кроме всего прочего такой текст:


[B]

   - Unfortunately, Microsoft has added a clever new
   - "feature" to Internet Explorer.  If the text in
   - an error's message is "too small", specifically
   - less than 512 bytes, Internet Explorer returns
   - its own error message.  Yes, you can turn that
   - off, but *surprise* it's pretty tricky to find
   - buried as a switch called "smart error
   - messages"  That means, of course, that many of
   - Resin's error messages are censored by default.
   - And, of course, you'll be shocked to learn that
   - IIS always returns error messages that are long
   - enough to make Internet Explorer happy.  The
   - workaround is pretty simple: pad the error
   - message with a big comment to push it over the
   - five hundred and twelve byte minimum.  Of course,
   - that's exactly what you're reading right now.
  
[/B]

вот так вот. вот нафига было делать такую фичу, чтобы сообщения об ошибках от всех остальных серверов скрывались?



[QUOTE mavin tm]прикол недавно обнаружил, может всем известный конечно

посмотрел в соурс сообщения об ошибке от resin и увидел кроме всего прочего такой текст:


[B]

   - Unfortunately, Microsoft has added a clever new
   - "feature" to Internet Explorer.  If the text in
   - an error's message is "too small", specifically
   - less than 512 bytes, Internet Explorer returns
   - its own error message.  Yes, you can turn that
   - off, but *surprise* it's pretty tricky to find
   - buried as a switch called "smart error
   - messages"  That means, of course, that many of
   - Resin's error messages are censored by default.
   - And, of course, you'll be shocked to learn that
   - IIS always returns error messages that are long
   - enough to make Internet Explorer happy.  The
   - workaround is pretty simple: pad the error
   - message with a big comment to push it over the
   - five hundred and twelve byte minimum.  Of course,
   - that's exactly what you're reading right now.
  
[/B]

вот так вот. вот нафига было делать такую фичу, чтобы сообщения об ошибках от всех остальных серверов скрывались?[/QUOTE]
Трудный вопрос, но думаю, что большинству пользователей эти сообщения об ошибках "до лампочки" и в среде разработчиков считается правилом хорошего тона все сообщения об ошибках сводить к минимуму, типа "произошла оштбка - админ оповещен" [:)]

Но мысль я Вашу понял насчет продвижения решений от одной компании [:)]



не совсем до лампочки.

вот вас ваш форум оповестил что в первоначальном виде сообщение этого топика я не смог опубликовать? эксепшн вывалился.

а вообще когда кастомер находится далеко - послать скриншот или скопипастить с экрана - простейший способ продиагностировать проблему.

ессно что все должно работать правильно и все ошибки должны обрабатываться грамотно. но не всегда получается однако.



[QUOTE mavin tm] а вообще когда кастомер находится далеко - послать скриншот или скопипастить с экрана - простейший способ продиагностировать проблему.[/QUOTE]
Сейчас у меня внедряется моя программа в двух филиалах. В общем-то ничего сложного - обычный толстый клиент с удаленным доступом через Интернет к корпоративной базе данных через Web Service. При отсутсвии соединения выдается exseption с кодом ошибки 0... Чтобы местные админы не делали - код ошибки и screen shot один и тот-же... Так что это мало что дает [:)] Приходится им объяснять что делать, хотя для начала промоделировали большинство возможных проблем в локальной сети и сделал Web page с подробными инструкциями, но кто читает в наше время инструкции при живом разработчике [:D]



ну вот дык если бы сообщение об ошибки было вменяемым а не "код 0" и куда то вывалился стэк (в сообщение или в лог), то продиагностировать ошибку было бы на порядок легче.

я как то для этого дела сделал так, чтобы все эксепшены которые вылетели наверх перед тем как показываться пользователю записывались в БД. а потом параметром командной строки можно было это дело вывести в текст.файл - за день, за неделю, за месяц. очень даже удобно и легко решать проблемы у удаленных клиентов. заодно видно где переглючило, а пользователь умолчал.



[QUOTE mavin tm]я как то для этого дела сделал так, чтобы все эксепшены которые вылетели наверх перед тем как показываться пользователю записывались в БД. а потом параметром командной строки можно было это дело вывести в текст.файл - за день, за неделю, за месяц. очень даже удобно и легко решать проблемы у удаленных клиентов. заодно видно где переглючило, а пользователь умолчал.[/QUOTE]
Интересный поход... Я его использую на данном сайте, правда для надежности пишу ошибки в текстовый файл - вдруг сам SQL Server "лежит"...

Ну а в практических приложениях я давно уже не пишу подобных вещей, так как в основном использую Visual FoxPro (а там все работает довольно стабильно, точнее хорошо вычистили за десяток лет и все glich как правило вылазают на стадии разработки и тестирования)...



при чем тут надежность фокспро. я про ошибки в софте, допущенные девелопером.
и к сожалению реальность такова, что не все удается выловить на этапе разработки и тестирования, особенно в сложных проектах.

по поводу надежности записи логов. я подумал так. у нас был оракл, и он просто так не "лежит" :) , но если уж БД отвалилась, то аппликация все равно работать не будет и это уже не к разработчикам, а к админам. т.е. в этом случае ошибка одна и диагностировать нечего. главное чтобы пользователю внятное сообщение выдалось.



[QUOTE mavin tm] при чем тут надежность фокспро. я про ошибки в софте, допущенные девелопером.[/QUOTE]
Не хочу выглядеть крутым, но после полутора десятков лет их почти нет  [:)] Если только сам клиент на этапе разработки задачи чего-то не намудрил, но это уже как говорится, "другая песня"... Ну и в FoxPro, конечно своя идеология разработок программ - там все делается на порядок быстрее, чем в любых средах разработки...
[QUOTE mavin tm]и к сожалению реальность такова, что не все удается выловить на этапе разработки и тестирования, особенно в сложных проектах. [/QUOTE]
В общем-то верно, но у меня пока реальность такова, что это уже не актуально... Сложные проекты запускаются по частям, иногда делаю пилотные проекты...
[QUOTE mavin tm]по поводу надежности записи логов. я подумал так. у нас был оракл, и он просто так не "лежит" :) , но если уж БД отвалилась, то аппликация все равно работать не будет и это уже не к разработчикам, а к админам. т.е. в этом случае ошибка одна и диагностировать нечего. главное чтобы пользователю внятное сообщение выдалось. [/QUOTE]
Я привел простой пример из области ASP.NET - если SQL server лежит, то все равно приложение работает - то есть клиент видит картинку в своем Browser с сайта, другое дело, что он уже ничего полезного получить не может [:(]



в большом и сложном проекте работает больше чем один человек. и даже если вы пишете код без ошибок, качество работы остальных вы не можете предсказать.



[QUOTE mavin tm]в большом и сложном проекте работает больше чем один человек. и даже если вы пишете код без ошибок, качество работы остальных вы не можете предсказать.[/QUOTE]
Вот тут я полностью согласен...

Но в последнее время я как-то отошел от разработок программ большими командами - обычно максимум два-три проверенных человека [:)]