|
|
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
пусть есть функция func в которой может возникнуть исключение. У нас есть 2 варианта 1. поймать в ней исключение и вернуть какойто результат типа bool func() { bool res = true; try { } catch() { res = false; } return res; } 2. Можно не ловить. Для каких то библиотечных функций понятно первый вариант предпочтилен, хотя с другой стороны даже библиотечные функции часто документированно кидадют эксепшены. Так вот я про плюсы второго метода, собсвтенно он один - меньше кода, а то что не возвращается значение не имеет значения ибо если у нас есть вложенность void func3() { func2(); } void func2() { func(); } то мы задолбаемся прокидывать наверх какие то осмысленные коды возврата (если это не тру фалс конечно, так действительно просто). Вот интересует как лучше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 16:02 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Подавлять никогда не надо - либо обрабатываешь осмысленно, либо отправляешь выше, возможно оборачивая в исключение более высокого уровня (типа "не смог импортировать файл (потому, что доступ запрещен)") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 16:17 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
FatherSql, Пусть есть маленькая комната с кафельным полом. У нас есть два варианта: 1. Поставить ванну. 2. поставить унитаз. Вот интересует как лучше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 16:49 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
WebSharperПодавлять никогда не надо - либо обрабатываешь осмысленно, либо отправляешь выше, возможно оборачивая в исключение более высокого уровня (типа "не смог импортировать файл (потому, что доступ запрещен)")+1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 20:17 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
FatherSql, обычно придерживаются такой стратегии что исключения не должны "частить". Или дёргаться часто. На сотни-тысячи успешных callbacks у вас должен быть один исключительный. Исключения (в зависимости от реализации могут быть "дорогими в обслуживании". Они могут где-то выделять память. Поэтому не стоит их толкать внутрь цикла где факт исключения "зымыливается" и цикл повторяется Это bad practice. По возможности лучше использовать коды возврата если по смыслу callback это позволяет. Исключения удобно применять тогда где нужно "аварийно завершить всё". Например - отъехал сетевой диск. Вы сворачиваете весь стек вызовов который работает с ним. Остальное - вопросы дизайна вашей библиотек и предмет договрённостей между вами и теми кто эту библиотеку будет использовать. Обычно вы не кодите в вакууме. Вы оглядываетесь по сторонам. Смотрите как пишут в team, в проекте в корпорации или какие code conventions. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 01:46 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Ребята, все конкретики языка программирования и задачи эти все обсуждения бессмысленны. Нет общих правил, когда как нужно обрабатывать исключения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 14:17 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
FatherSqlпусть есть функция func в которой может возникнуть исключение. У нас есть 2 варианта 1. поймать в ней исключение и вернуть какойто результат типа Это редко является хорошим подходом. Собственно, я пожалуй что рискну утверждать, что во всех случаях, когда вообще стоит выбор "первый или второй вариант", первый явно не стоит использовать. FatherSqlТак вот я про плюсы второго метода, собсвтенно он один - меньше кода, Его главный плюс в том, что он гораздо надёжнее, по крайней мере "в среднем по больнице". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 18:43 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
softwarerFatherSqlпусть есть функция func в которой может возникнуть исключение. У нас есть 2 варианта 1. поймать в ней исключение и вернуть какойто результат типа Это редко является хорошим подходом. Собственно, я пожалуй что рискну утверждать, что во всех случаях, когда вообще стоит выбор "первый или второй вариант", первый явно не стоит использовать. FatherSqlТак вот я про плюсы второго метода, собсвтенно он один - меньше кода, Его главный плюс в том, что он гораздо надёжнее, по крайней мере "в среднем по больнице". чем надежнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 20:55 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Про обработку исключений говорят правильно, это идет из старых умных книжек, но сейчас в C++ часто вся обработка заключается в выходе из области видимости с вызовом деструкторов, а в catch() просто сообщается факт ошибки пользователю. Я использую исключения в случаях: 1. Когда удобно получать полезное возвращаемое значение: Код: plaintext 1. 2. 3. 4. 2. Когда при ошибке не имеет смысла использовать полученные данные из функции и вся обработка исключения заключается в выходе из области видимости и вызове деструкторов: Код: plaintext 1. 2. 3. 4. 5. 2. Когда одни и те же исключения могут выйти из нескольких функций: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. В остальных случаях return. В частности когда функцию пишет другой человек, в ней может возникнуть несколько разных исключений, причем их количество и тип может меняться разработчиком функции, то лучше, чтобы в самом интерфейсе функции была заложена классификация и сквозная нумерация ошибок, т.е. в h-файле enum который и возвращается. Но и в этом правиле бывают исключения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 21:07 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Допустим если функция имеет такой вид: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. С return и кодам ошибок выглядело бы так - больше кода и больше вложенности: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. И без RAII ещё бы в разы больше кода было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 21:57 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
FatherSqlчем надежнее Да много чем. Меньше кода - меньше ошибок. Код прозрачнее - меньше ошибок. Легче сопровождение, меньше сил на работу с кодами завершения - итогом всего является "меньше ошибок". Но самое главное - поведение при внесении изменений в другие части программы. Допустим, у нас в приложении используется некая функция. Всё работает без ошибок. В ходе доработок в ней появился новый код возврата - упс, нужно перепроверять все места её вызова. Если где-то вызывающий код останется "старым", последствия непредсказуемы; в том числе выполнение может пойти по ветке кода OK. Теперь та же ситуация, но в функцию добавлено новое исключение. Что происходит со старым кодом? Да ничего страшного, собственно. Исключение провалится до стандартного обработчика, который запишет в лог "произошла неожиданная ошибка такая-то", либо вообще не будет обработано и повалит приложение. То есть по крайней мере приложение не будет делать вид, что всё в порядке, не испортит данные и не попытается обработать ошибку А методами ошибки Б. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 23:13 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
softwarerВ ходе доработок в ней появился новый код возврата - упс, нужно перепроверять все места её вызова. Изначально надо писать код так, что необрабатываемые коды пишут в лог и валят приложение. Это можно сделать как исключениями, так и проверками кода возврата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 08:29 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
eNoseИзначально надо писать код так, что необрабатываемые коды пишут в лог и валят приложение. Во-первых, "нужно" не значит "везде будет". Я давно привык закладывать в подходы предположение, что программист ошибётся везде, где у него есть такая возможность. И в этом случае с кодами возврата будет наломано больше дров. Ну а во-вторых, далеко не всегда необрабатываемые коды должны валить приложение. Не так редко отказ какого-то модуля представляется меньшим злом, нежели отказ приложения в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 09:00 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Все твердят, что при неизвестном исключении надо его не обработать (валить приложение) с записью в лог. Хорошая практика. Да тут все понятно. Но скажите, товарищи, допустим наше приложение - веб-сервер. К которому приходят тысячи запросов. Один из этих запросов привел к неизвестному исключению. Приложение записало это в лог, и упало. 9999 успешно работающих сейчас коннектов завершились. Это Вы называете хорошей практикой? Иногда можно перехватывать любые исключений, проверять, если это исключение, после которого невозможно работать далее, то валить приложение. Если можно работать дальше, то валить, только эту ветку, а остальная часть кода должна продолжать функционировать. В лог запись конечно таких ошибок должна быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 09:49 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeВсе твердят, что при неизвестном исключении надо его не обработать (валить приложение) с записью в лог. Хорошая практика. Да тут все понятно. Но скажите, товарищи, допустим наше приложение - веб-сервер. К которому приходят тысячи запросов. Один из этих запросов привел к неизвестному исключению. Приложение записало это в лог, и упало. 9999 успешно работающих сейчас коннектов завершились. Это Вы называете хорошей практикой?Это Вы фигню какую-то выдумали. Отдельный запрос получит 500-ю, или 404-ю (обычно если исключения перехватывают, пишут в лог, то отдают ответ с этим кодом), остальные успешно продолжат работать дальше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 10:35 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeВсе твердят, что при неизвестном исключении надо его не обработать (валить приложение) с записью в лог. Хорошая практика. Да тут все понятно. Но скажите, товарищи, допустим наше приложение - веб-сервер. К которому приходят тысячи запросов. Один из этих запросов привел к неизвестному исключению. Приложение записало это в лог, и упало. 9999 успешно работающих сейчас коннектов завершились. Это Вы называете хорошей практикой? Где уверенность что перед исключением не было записи "мусора" в память, которой пользуется один из 9999 успешных? Можно утверждать что все 9999 вернут достоверный результат? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 10:44 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Dima TГде уверенность что перед исключением не было записи "мусора" в память, Ровно там же, где уверенность, что записи "мусора" в память не было без всякого исключения (или при коде возврата OK). Вы так смешно говорите, словно вызываемый любезно возвращает специальную ошибку, "господа, я насрал вам в оперативку" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 10:47 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Dima T, разработчики .NET и IIS windows с Вами не согласны. Проверьте - создайте свой сайт ASP.NET при запросе бросьте своё исключение и не обрабатывайте его. После этого IIS не упадет, а будет нормально работать дальше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 10:48 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
skyANA, и как же он получит ответ на http-запрос, если в коде не обработаете это исключение? Я Вам про это и вещаю, что иногда надо обрабатывать любое исключение, даже неизвестное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 10:49 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
eNosesoftwarerВ ходе доработок в ней появился новый код возврата - упс, нужно перепроверять все места её вызова . Изначально надо писать код так, что необрабатываемые коды пишут в лог и валят приложение. Это можно сделать как исключениями, так и проверками кода возврата. Это да! Как и в исключениях они ловятся через catch(...), так и в кодах возврата они ловятся через else в if или в default в case. Но удобство исключений в том, что отлавливать такие неизвестные исключения можно в одном месте сразу для 10 функций, а неизвестные коды возврата надо проверять для каждой функции - больше кода . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 13:38 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeИногда можно перехватывать любые исключений, проверять, если это исключение, после которого невозможно работать далее, то валить приложение. Если можно работать дальше, то валить, только эту ветку, а остальная часть кода должна продолжать функционировать. В лог запись конечно таких ошибок должна быть. Есть и третий вариант, когда неизвестно невозможно или можно работать дальше - неизвестное исключение/код возврата. В этом случае предполагается худший вариант - невозможно. Но идут всегда на компромисс, просто все потоки и подключения изначально поделены между несколькими процессами с изолированной памятью, и падает только один из процессов. Лучше если 10% соединений передподключатся, чем вместо 1 000 спишется 1 000 000 руб в биллинге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 13:39 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Иногда бывают ситуации когда обрабатывать что-либо уже поздно. К примеру совершенно непонятно как надо обрабатывать java.lang.OutOfMemoryError. Оно вроде бы и ежу ясно что постфактумом анализировать увеличивать mX, анализировать дамп и делать прочие неспешные акты. Но что делать в рилтайме? Вроде уже и нечего. Можно только рухнуть в лог с уровнем FATAL, или MEGA_FATAL, ... или саркастически написать какой-то афоризм... типа "Вечны смерть, налоги и нехватка хипа...." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 14:35 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
maytonкак надо обрабатывать java.lang.OutOfMemoryError. Но что делать в рилтайме? Закрыть только это соединение с сообщением об ошибке. Остальные соединения уже себе память выделили - пусть работают. Плюс в такой ситуации можно в течении X минут сразу отлупливать новые соединения, где X - среднее время жизни одного соединения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:07 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася Уткинsuper-codeИногда можно перехватывать любые исключений, проверять, если это исключение, после которого невозможно работать далее, то валить приложение. Если можно работать дальше, то валить, только эту ветку, а остальная часть кода должна продолжать функционировать. В лог запись конечно таких ошибок должна быть. Есть и третий вариант, когда неизвестно невозможно или можно работать дальше - неизвестное исключение/код возврата. В этом случае предполагается худший вариант - невозможно. Но идут всегда на компромисс, просто все потоки и подключения изначально поделены между несколькими процессами с изолированной памятью, и падает только один из процессов. Лучше если 10% соединений передподключатся, чем вместо 1 000 спишется 1 000 000 руб в биллинге. И с вами не согласны разработчики .NET и IIS, пример приводил. Также не согласны разработчики ms sql server. Попробуйте в ms sql server зарегистрировать свою сборку, при её вызове бросать exception. Сделайте запрос sql к серверу и с вызовом вашей сборки. Служба sql server не упадет, а только ответит ошибкой - служба обрабатывает любое исключение, даже не зная о чем оно. А если служба знает, что за исключение и уверена, что дальше работать нельзя, то тогда падает. И ни на какие части подключенные к sql server не делятся путем запуска нескольких процессов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:08 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин, я привел уже пару примеров мировых продуктов, которые обрабатывают любое исключение. И готов привести ещё 10 (если не мировых, то очень известных). А вы можете к своей теории добавить практику - привести пример известного продукта, в который можно внедрять свои разработки, и при неизвестном исключении весь процесс будет падать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:12 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeВася Уткинпропущено... Есть и третий вариант, когда неизвестно невозможно или можно работать дальше - неизвестное исключение/код возврата. В этом случае предполагается худший вариант - невозможно. Но идут всегда на компромисс, просто все потоки и подключения изначально поделены между несколькими процессами с изолированной памятью, и падает только один из процессов. Лучше если 10% соединений передподключатся, чем вместо 1 000 спишется 1 000 000 руб в биллинге. И с вами не согласны разработчики .NET и IIS, пример приводил. Также не согласны разработчики ms sql server. Попробуйте в ms sql server зарегистрировать свою сборку, при её вызове бросать exception. Сделайте запрос sql к серверу и с вызовом вашей сборки. Служба sql server не упадет, а только ответит ошибкой - служба обрабатывает любое исключение, даже не зная о чем оно. А если служба знает, что за исключение и уверена, что дальше работать нельзя, то тогда падает. И ни на какие части подключенные к sql server не делятся путем запуска нескольких процессов. Это архитектура приложения. Например в MSSQL расширенная процедура запускается в изолированном процессе. Нечто подобное происходит и с запуском .NET сборки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:25 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вы спорите ниочём. Это вопрос протокола и договорённостей. И возможно стоит обсудить доп. условия. Язык. Среда. Сильною/слабую связность компонентов. Модульность. Выгружаемость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:32 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeВася Уткинпропущено... Есть и третий вариант, когда неизвестно невозможно или можно работать дальше - неизвестное исключение/код возврата. В этом случае предполагается худший вариант - невозможно. Но идут всегда на компромисс, просто все потоки и подключения изначально поделены между несколькими процессами с изолированной памятью, и падает только один из процессов. Лучше если 10% соединений передподключатся, чем вместо 1 000 спишется 1 000 000 руб в биллинге. И с вами не согласны разработчики .NET и IIS, пример приводил. Также не согласны разработчики ms sql server. Попробуйте в ms sql server зарегистрировать свою сборку, при её вызове бросать exception. Сделайте запрос sql к серверу и с вызовом вашей сборки. Служба sql server не упадет, а только ответит ошибкой - служба обрабатывает любое исключение, даже не зная о чем оно. А если служба знает, что за исключение и уверена, что дальше работать нельзя, то тогда падает. И ни на какие части подключенные к sql server не делятся путем запуска нескольких процессов. А вы уверены, что ваша процедура запускается в одном процессе с самой СУБД, и что не закрывается весь процесс в котором запускается процедура? И что если произойдет критическое исключение в коде самой СУБД, то СУБД продолжит работать? Разработчики .NET и IIS согласны со здравым смыслом и со мной :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:45 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин, что в ms sql server, а также IIS и .NET не появляется отдельного процесса - уверен. Так, что с Вашей практикой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:53 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
maytonК примеру совершенно непонятно как надо обрабатывать java.lang.OutOfMemoryError. ... Но что делать в рилтайме? Ну например: 0. Отпустить прибережённый для этой цели резерв 1. Гробануть обработку конкретного запроса, если этого не случилось в ходе разматывания стека 2. Если после этого памяти стало нормально, продолжить работу, опционально настучав по голове автору запроса на тему "поумерь аппетиты" 3. Если после этого памяти останется мало, сбросить всяческие кэши и подрезать параметры типа "максимальный размер", "максимум одновременно работающих" итп. 4. Когда памяти станет нормально, не забыть снова выделить аварийный буфер 5. Если пункт 3 начинает повторяться с надоедливым постоянством, написать разработчикам "поднимите свои задницы и ищите, где утечка памяти, пока я совсем не сдох", улучшить момент и перезапуститься ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:57 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeskyANA, и как же он получит ответ на http-запрос, если в коде не обработаете это исключение?Простите, а что он получит по Вашему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:59 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
mayton, я с Вами согласен. Существуют ситуации, когда надо обрабатывать любое исключение, а существуют, когда не надо. И это вопрос архитектуры. Но Вася Уткин уверен, что подход настоящего джедая один - не обрабатывать неизвестные исключения и код вида: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Это говнокод. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 15:59 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
skyANA, если мой процесс - веб-сервер, и он упадет. То клиент ничего не получит. У вас другое мнение на этот счет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:00 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeВася Уткин, что в ms sql server, а также IIS и .NET не появляется отдельного процесса - уверен. Так, что с Вашей практикой? в случае с .NET появляется виртуальная машина. В случае с реальным кодом - процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:02 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
locked, только что создал новый сайт на iis 7. Страница на asp.net (.net 4.0) при загрузке ждет 3 секунды (sleep), потом бросает исключение. Следил за кол-вом процессов. Оно - 39, как до запуска страницы, так во время работы, так и после. Процессов новых не появлялось, все выполняется там же. Осталось понять, что вы подразумеваете под виртуальной машиной (vmware) тоже не запустился? Если единственный аргумент не перехватывать неизвестные исключения - это возможная порча памяти. Так я открою вам глаза - в windows можно записать данные и в память чужого процесса. Поэтому советую после неизвестного исключения - сразу перезагружать компьютер - так надежнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:11 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeskyANA, если мой процесс - веб-сервер, и он упадет. То клиент ничего не получит. У вас другое мнение на этот счет?Не, ну если веб-сервер упадёт... А понял, я с утра не внимательно прочитал Ваше первое сообщение. Там речь о веб-сервере. Я же прочитал как веб-сервис. Ошибочка вышла ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:12 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
locked, если под виртуальной машиной подразумевается новый домен приложения: http://msdn.microsoft.com/en-us/library/system.appdomain.createdomain(v=vs.90).aspx То было бы очень интересно послушать, как это реализовано без перехвата неизвестных исключений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:13 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeЕсли единственный аргумент не перехватывать неизвестные исключения - это возможная порча памяти. Так я открою вам глаза - в windows можно записать данные и в память чужого процесса. Поэтому советую после неизвестного исключения - сразу перезагружать компьютер - так надежнее. Но это по-прежнему никак не мешает испортить память без всяких неизвестных исключений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:15 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codelocked, только что создал новый сайт на iis 7. Страница на asp.net (.net 4.0) при загрузке ждет 3 секунды (sleep), потом бросает исключение. Следил за кол-вом процессов. Оно - 39, как до запуска страницы, так во время работы, так и после. Процессов новых не появлялось, все выполняется там же. Осталось понять, что вы подразумеваете под виртуальной машиной (vmware) тоже не запустился? я имел ввиду "виртуальная машина .NET" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:15 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
locked, "виртуальная машина .net" работает внутри процесса. Например, с каждым новым процессом на .net появляется свой сборщик мусора для этого процесса. Т.е. IIS в своем процессе запустил мой код на .net, перехватил неизвестное исключение, и продолжает работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:20 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codelocked, "виртуальная машина .net" работает внутри процесса. Например, с каждым новым процессом на .net появляется свой сборщик мусора для этого процесса. Т.е. IIS в своем процессе запустил мой код на .net, перехватил неизвестное исключение, и продолжает работать. Твой "код на .NET" это IL код который интерпретируется "виртуальной машиной .NET" и твои эксепшены в нем никак не связаны с реальными эксепшенами IIS процесса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:31 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
softwarer0. Отпустить прибережённый для этой цели резерв 1. Гробануть обработку конкретного запроса, если этого не случилось в ходе разматывания стека 2. Если после этого памяти стало нормально, продолжить работу, опционально настучав по голове автору запроса на тему "поумерь аппетиты" 3. Если после этого памяти останется мало, сбросить всяческие кэши и подрезать параметры типа "максимальный размер", "максимум одновременно работающих" итп. 4. Когда памяти станет нормально, не забыть снова выделить аварийный буфер 5. Если пункт 3 начинает повторяться с надоедливым постоянством, написать разработчикам "поднимите свои задницы и ищите, где утечка памяти, пока я совсем не сдох", улучшить момент и перезапуститься Нет такой практики. Держать резервы. По поводу настучать по голове автору - полностью согласен. Но это уже после краша приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:35 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
locked, что значит никак не связаны? 1. Процесс тот же? - тот же; 2. Exception был? - был; 3. Его кто-то обработал или процесс убал? - нет процесс не упал, exception обработан. 4. Мы его в своем коде обратывали? - нет, его обработал iis и среда .net. Вот он ответ на твой вопрос. Или ты считаешь, как-то по другому? Если я на той же странице сделаю бесконечную рекурсию, то получится exception - stack overflow. Тогда весь процесс iis упадет, и это будет видно в логах windows. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:35 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
maytonНет такой практики. Держать резервы. Ты просто тему про хвостики в массивах не читал :D ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:38 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codemaytonНет такой практики. Держать резервы. Ты просто тему про хвостики в массивах не читал :D Это в каком языке/технологии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:39 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
mayton, первоисточник найти не смог, но продолжение тут http://www.gamedev.ru/flame/forum/?id=122958 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 16:44 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codemayton, я с Вами согласен. Существуют ситуации, когда надо обрабатывать любое исключение, а существуют, когда не надо. И это вопрос архитектуры. Но Вася Уткин уверен, что подход настоящего джедая один - не обрабатывать неизвестные исключения и код вида: Вот это вы уже сами придумали. super-codeЕсли единственный аргумент не перехватывать неизвестные исключения - это возможная порча памяти. Так я открою вам глаза - в windows можно записать данные и в память чужого процесса. И как же это сделать без разделяемой памяти и привилегий? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:03 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин, программу ArtMoney видел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:05 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася УткинВот это вы уже сами придумали. Я заявил, что бывают ситуации, когда стоит обработать неизвестное исключение и НЕ бросать его далее наружу, привел, как пример - веб-сервис. Ты мне ответил: Вася Уткин...неизвестное исключение/код возврата. В этом случае предполагается худший вариант - невозможно. Но идут всегда на компромисс, просто все потоки и подключения изначально поделены между несколькими процессами с изолированной памятью, и падает только один из процессов. Лучше если 10% соединений передподключатся, чем вместо 1 000 спишется 1 000 000 руб в биллинге. Я из этой фразы сделал вывод, что ты со мной не согласен, и считаешь, что никогда не следует обрабатывать неизвестное исключение. Или я неверный вывод сделал, и ты не согласен, только с моим примером? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:13 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-code, как пример, я привел - веб-СЕРВЕР, опечатка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:14 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин super-codeЕсли единственный аргумент не перехватывать неизвестные исключения - это возможная порча памяти. Так я открою вам глаза - в windows можно записать данные и в память чужого процесса. И как же это сделать без разделяемой памяти и привилегий ? super-codeВася Уткин, программу ArtMoney видел? http://www.artmoney.ru/manual/russian/faq.htm апустить программу ArtMoney Pro через контекстное меню "Запустить от имени Администратора " ( в английской версии "Run As Administrator " ) Бурная у тебя фантазия, мало того, что у тебя внешние процедуры запускаются не в отдельном заранее созданном процессе, так ещё и с правами администратора. Зачем тогда по твоему вообще процессы были созданы, жизнь усложнить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:17 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася Уткин, про права я тебе ничего не говорил. Кто тебе гарантирует, что твой сервис у заказчика работает не от имени администратора? или соседний сервис. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:20 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codemayton, первоисточник найти не смог, но продолжение тут http://www.gamedev.ru/flame/forum/?id=122958 Сходу многобукв. И тема какая-то стрёмная. Хвостики какие-то. Сходу если это суть - перегрузка аллокатора то неинтересно. Да и накладно как-то... Хотя почитаю. Возможно стоит и отдельную ветку поднять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:36 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
mayton, не, это не серьезно все. Суть такова: один товарищ очень активно доказывал, что если вам нужен статический массив на 100 элементов, выделите массив на 120 (20 - хвостик). И когда вы ошибетесь в границах массива, ваше приложение не упадет... Ему сначала объясняли, а потом все согласились с ним и долго друг друга стебали, при любой непонятной ошибки, что нужно было использовать хвостики в массивах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:45 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
maytonНет такой практики. Держать резервы. В яве это уже и не сказать чтобы критично, скорее для порядка упомянул. Там и так прорва всего, что можно освободить и что освободится автоматически в результате размотки стека. maytonПо поводу настучать по голове автору - полностью согласен. Но это уже после краша приложения. Ну это как хотите. Думаю, я показал, что в ситуации таки можно кое-что сделать, хотя нарисовано сходу и список явно неполный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:46 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Почему накинул 20% ? Почему не 1% или 200% ? Какой вобще в этом есть научный метод? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:48 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
И потом. Этож ошибку в софте не устраняет. Это просто ее скрывает от разработчика и надолго. Делал процессинг 1000 элементов. Суммы средие почсчитал там.. аналитику. Софт учёл 1001 элемент. Ошибку доступа не выдал. Ты доволен. А аналитика - не та. Ну не то чтобы совсем не та. Но чуть-чуть другая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 17:54 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
mayton, в этом и была суть всего смеха. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 18:00 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
super-codeВася Уткин, про права я тебе ничего не говорил. Кто тебе гарантирует, что твой сервис у заказчика работает не от имени администратора ? или соседний сервис. Внезапно! Администратор. Который пришел на замену уволенному - известно по какой причине. На системах, где считаются деньги или содержится конфиденциальная информация недопустимо запускать сервисы/приложения под Администратором ровно так же, как и устанавливать например Perform Volume Maintenance. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 18:22 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
softwarerВы так смешно говорите, словно вызываемый любезно возвращает специальную ошибку, "господа, я насрал вам в оперативку" :)Да, такая ошибка была бы весьма полезной. С точки зрения разработчика СУБД, случаи "кинул исключение и наверное нагадил в оперативку" и "кинул исключение, но скорее всего не нагадил" отличаются очень просто. Модуль от обычного апп-девелопера наверное нагадил, наш модуль или модуль из другой хорошей библиотеки или СУБД скорее всего отработал чисто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 18:28 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
maytonТы доволен. А аналитика - не та. Ну не то чтобы совсем не та. Но чуть-чуть другая. Первое, чему меня учили в аналитике - что трепетное олтп-шное отношение к корректности каждой строчки можно забыть, посчитать аналитику по 990, откинув 10 инвалидов - несравнимо лучше, чем из-за инвалидов отказаться считать всю тысячу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 23:04 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
iv_an_ruС точки зрения разработчика СУБД, случаи "кинул исключение и наверное нагадил в оперативку" и "кинул исключение, но скорее всего не нагадил" отличаются очень просто. В любом случае, наибольший интерес представляет вариант "нагадил, гад, и не кинул никакого исключения". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 23:06 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
softwarermaytonТы доволен. А аналитика - не та. Ну не то чтобы совсем не та. Но чуть-чуть другая. Первое, чему меня учили в аналитике - что трепетное олтп-шное отношение к корректности каждой строчки можно забыть, посчитать аналитику по 990, откинув 10 инвалидов - несравнимо лучше, чем из-за инвалидов отказаться считать всю тысячу.У меня сегодня запрос от юзера --- можно ли "отредактировать" контроль данных, чтобы география перестала ругаться на точки с широтой больше 90 и меньше минус 90, но продолжала ругаться на точки с широтой больше 97 и меньше минус 97 :) Бедолаги раскладывают данные на три кучки: приличные, полное гэ и гэ частичное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2014, 00:50 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася Уткинsuper-codeВася Уткин, про права я тебе ничего не говорил. Кто тебе гарантирует, что твой сервис у заказчика работает не от имени администратора ? или соседний сервис. Внезапно! Администратор. Который пришел на замену уволенному - известно по какой причине. На системах, где считаются деньги или содержится конфиденциальная информация недопустимо запускать сервисы/приложения под Администратором ровно так же, как и устанавливать например Perform Volume Maintenance. Да причем тут деньги? Я тебе привел пример - веб-сервер, он может не только деньги считать, если что, и будет лучше если он не будет падать от неизвестного ему исключения в дочерним плагине написанном на управляемом языке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2014, 09:55 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася УткинНо идут всегда на компромисс, просто все потоки и подключения изначально поделены между несколькими процессами с изолированной памятью, и падает только один из процессов . Лучше если 10% соединений передподключатся, чем вместо 1 000 спишется 1 000 000 руб в биллинге. super-codeВася Уткинпропущено... Внезапно! Администратор. Который пришел на замену уволенному - известно по какой причине. На системах, где считаются деньги или содержится конфиденциальная информация недопустимо запускать сервисы/приложения под Администратором ровно так же, как и устанавливать например Perform Volume Maintenance. Да причем тут деньги? Я тебе привел пример - веб-сервер, он может не только деньги считать, если что, и будет лучше если он не будет падать от неизвестного ему исключения в дочерним плагине написанном на управляемом языке. А веб-сервер и не будет падать если исключение произойдет в отдельном процессе "в дочерним плагине написанном на управляемом языке", а упадет и перезапустится только этот отдельный процесс и переподключатся соединения его использующие в данный момент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2014, 12:03 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
iv_an_rusoftwarerпропущено... Первое, чему меня учили в аналитике - что трепетное олтп-шное отношение к корректности каждой строчки можно забыть, посчитать аналитику по 990, откинув 10 инвалидов - несравнимо лучше, чем из-за инвалидов отказаться считать всю тысячу.У меня сегодня запрос от юзера --- можно ли "отредактировать" контроль данных, чтобы география перестала ругаться на точки с широтой больше 90 и меньше минус 90, но продолжала ругаться на точки с широтой больше 97 и меньше минус 97 :) Бедолаги раскладывают данные на три кучки: приличные, полное гэ и гэ частичное. Спроси как они поступают с углами от 90 до 97. Просто интерсно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2014, 13:23 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вася УткинА веб-сервер и не будет падать если исключение произойдет в отдельном процессе "в дочерним плагине написанном на управляемом языке", а упадет и перезапустится только этот отдельный процесс и переподключатся соединения его использующие в данный момент. IIS в windows работает по другому. Доказательства приводил. Но Вася, конечно, знает лучше, чем галимый Microsoft как надо писать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2014, 14:51 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
maytoniv_an_ruпропущено... У меня сегодня запрос от юзера --- можно ли "отредактировать" контроль данных, чтобы география перестала ругаться на точки с широтой больше 90 и меньше минус 90, но продолжала ругаться на точки с широтой больше 97 и меньше минус 97 :) Бедолаги раскладывают данные на три кучки: приличные, полное гэ и гэ частичное. Спроси как они поступают с углами от 90 до 97. Просто интерсно Разобрался уже. У них кроме реальных данных есть сколько-то bounding box--ов, вычисленных для дуг по приближённым алгоритмам. Формально утверждение "широты всех точек данных фигур лежат в диапазоне от 70 до 97" ничем не менее правильно, чем утверждение "... от 70 до 90". Ещё там ненулевое количество ошибок округления вокруг полюсов и ошибок, связанных с вычислением дуг на сфере вместо вычислением дуг на геоиде. Эти два сорта они вроде как умеют различать и частично исправлять, выясняя сначала, какие источники по каким причинам и какими способами косячат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2014, 15:11 |
|
||
|
Когда подавлять исключения а когда пропускать?
|
|||
|---|---|---|---|
|
#18+
Вообще, и у экзепшнов, и у возвращаемых значений две цели: 1) сигнализация об ошибках для разработчиков 2) сигнализация об ошибках для самой программы Ошибки для разработчиков нужно выдавать все в отладке, и только нештатные в релизе. Нештатные должны валить исполнение, иначе отладка и тестирование будут на "два с плюсом" - "три с минусом". Ошибки для программы должны обрабатываться всегда. Иначе нет уверенности в том, что ваша программа что-то сделала, а что-то не сделала. Т.е. когда выполняется строчка кода, сам факт того, что до неё дошло исполнение должен свидетельствовать о целостности, и безошибочности всего, что нужно этой строчке кода. Или, по крайней мере всё, что необходимо, должно тут же проверяться. Иначе результат работы этой строчки кода будет даже хуже чем ошибочен - не определён. Я придерживаюсь мнения, что весь код в программе должен определённо работать, а не на удачу. Код должен работать, или не работать фактически, а не статистически. Поэтому, нужно компактно и эффективно проверять все предыдущие вызовы, а значит и вообще все вызовы в программе, где может возникнуть хоть какая-то реальная ошибка (например выделение памяти, или неверное значение указателя на функцию). Проигнорировать результат проверки вы всегда успеете. А вот месяцами и годами искать в крупном корпоративном продукте источник редких ошибок - это верный результат отношения к ошибкам: "рано или поздно всё равно отладится". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2014, 20:34 |
|
||
|
|

start [/forum/topic.php?all=1&fid=16&tid=1341251]: |
0ms |
get settings: |
9ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
176ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
128ms |
get tp. blocked users: |
2ms |
| others: | 234ms |
| total: | 595ms |

| 0 / 0 |
