Почему в Исключениях не Регистрируются.NET?
Команда x = Symbol('x') сохраняет символ Symbol('x') Sympy в переменной Python x. Выражение Sympy f, которое вы создаете впоследствии, содержит Symbol('x'), а не переменную Python x.
Когда вы переназначаете x = 0, переменная Python x установлена на ноль и больше не относится к Symbol('x'). Это не влияет на выражение Sympy, которое все еще содержит Symbol('x').
Это лучше всего объяснить на этой странице документации Sympy: http://docs.sympy.org/latest/ gotchas.html # variables
Что вы хотите сделать, это f.subs(x,0), как сказано в других ответах.
10 ответов
Поскольку ответ на контролируемые исключительные ситуации почти всегда:
try {
// exception throwing code
} catch(Exception e) {
// either
log.error("Error fooing bar",e);
// OR
throw new RuntimeException(e);
}
, Если Вы на самом деле знаете, что существует что-то, которое можно сделать, если конкретное исключение выдается, то можно поймать его и затем обработать его, но иначе это - просто заклинания для успокоения компилятора.
Философия базовой конструкции C# - то, что на самом деле ловля исключений редко полезна, тогда как чистка ресурсов в исключительных ситуациях довольно важна. Я думаю, что справедливости ради стоит отметить, что using (шаблон IDisposable) их ответ на контролируемые исключительные ситуации. См. [1] для больше.
Интересно, парни в Microsoft Research добавили контролируемые исключительные ситуации к Spec#, их надмножество C#.
Я пошел от Java до C# из-за смены работы. Сначала, я был немного обеспокоен различием, но на практике, это не имело значения.
, Возможно, именно, потому что я происхожу из C++, имеет описание исключения, но это не является наиболее часто используемым. Я пишу каждую строку кода, как будто это могло бросить - всегда используют использование вокруг Доступного и думают об очистке, в которой я должен выполнить наконец.
Ретроспективно распространение объявления вызовов в Java действительно не получило меня ничто.
я хотел бы способ сказать, что функция определенно никогда не бросает - я думаю, что это было бы более полезно.
К тому времени, когда.NET была разработана, Java имел контролируемые исключительные ситуации в течение достаточно долгого времени, и эта функция просматривалась Java-разработчиками в лучшем случае как , спорный , спорный . Таким образом разработчики.NET выбрали not to include it in C# language.
Дополнительно к ответам, которые уже были записаны, не наличие контролируемых исключительных ситуаций помогает Вам во многих ситуациях много. Контролируемые исключительные ситуации делают дженерики тяжелее для реализации и если Вы прочитали предложения по закрытию, Вы заметите, что каждое предложение по закрытию должно работать вокруг контролируемых исключительных ситуаций довольно ужасным способом.
Я иногда пропускаю контролируемые исключительные ситуации в C#/.NET.
я предполагаю помимо Java, никакая другая известная платформа не имеет их. Возможно, парни.NET просто пошли с потоком...
В статье Проблема с Контролируемыми исключительными ситуациями и в Anders Hejlsberg (разработчик языка C#) собственная речь, существует три главных причины для C#, не поддерживающего контролируемые исключительные ситуации, поскольку они найдены и проверены в Java:
-
Нейтральный на Контролируемых исключительных ситуациях
“C# в основном тих по проблеме контролируемых исключительных ситуаций. Как только лучшим решением является known—, и доверяйте мне, мы продолжаем думать о it—, мы можем возвратиться и на самом деле поместить что-то на месте. ”
-
Управление версиями с Контролируемыми исключительными ситуациями
“Adding новое исключение к пункту бросков в новой версии повреждает клиентский код. Это похоже на добавление метода к интерфейсу. После публикации интерфейса это во всех неизменных практических целях, †¦ ”
, “It забавен, как люди думают, что важная вещь об исключениях обрабатывает их. Это не важная вещь об исключениях. В правильно написанном приложении существует отношение десять одному, по-моему, попытки наконец для попытки выгоды. Или в C#,
usingоператоры, которые похожи на попытку наконец. ” -
Масштабируемость Контролируемых исключительных ситуаций
“In, который небольшие, контролируемые исключительные ситуации очень enticing†¦ проблема, начинается, когда Вы начинаете создавать большие системы, где Вы говорите с четырьмя или пятью различными подсистемами. Каждая подсистема выдает четыре - десять исключений. Теперь, каждый раз, когда Вы идете по лестничной структуре агрегирования, у Вас есть эта экспоненциальная иерархия ниже Вас исключений, с которыми необходимо иметь дело. Вы заканчиваете тем, что имели необходимость объявить 40 исключений, которые Вы могли бы выдать. †¦ Это просто воздушные шары из-под контроля. ”
В его статье, “ , Почему не делает C#, имеют спецификации исключения? ”, Anson Horton (Визуальный Диспетчер Программ C#) также перечисляет следующие причины (см. статью для получения дополнительной информации о каждой точке):
- Управление версиями
- Производительность и качество кода
- Непрактичность наличия автора класса дифференцируется между [1 116], проверил , и снял флажок исключения
- Трудность определения корректных исключений для интерфейсов.
интересно отметить, что C# действительно, тем не менее, поддерживает документацию исключений, выданных данным методом через <exception> , тег и компилятор даже заботятся проверять, что тип исключительной ситуации, на который ссылаются, действительно существует. Нет, однако, никакой проверки, осуществленной на сайтах вызова или использовании метода.
можно также хотеть изучить Охотник за Исключением , который является коммерческим инструментом Red Gate Software , который использует статический анализ, чтобы определить и сообщить об исключениях, выданных методом и который может потенциально пойти непойманный:
Охотник за Исключением является новым аналитическим инструментом, который находит и сообщает о наборе возможных исключений, Ваши функции могли бы бросить †“перед ровной поставкой. С ним можно определить местоположение необработанных исключений легко и быстро, вниз к строке кода, который выдает исключения. Как только у Вас есть результаты, можно решить, какие исключения должны быть обработаны (с некоторым кодом обработки исключений), прежде чем Вы выпустите свое приложение на волю.
Наконец, Bruce Eckel , автор [1 110] Взгляды в Java, статья звонила, “ , Java нужны Контролируемые исключительные ситуации? ”, который может стоить считать также, потому что вопрос того, почему контролируемые исключительные ситуации не находятся там в C# обычно, пускает корни в сравнениях с Java.
Существенно, ли исключение должно быть обработано или не является свойством вызывающая сторона , а не функции.
, Например, в некоторых программах нет никакого значения в обработке IOException (полагайте, что специальные утилиты командной строки выполняют данные, уплотняющие; они никогда не собираются быть используемыми "пользователем", они - инструменты специалиста, используемые людьми специалиста). В некоторых программах существует значение в обработке IOException в точке "рядом" к вызову (возможно, если Вы получите FNFE для своего файла конфигурации, то Вы будете ронять к некоторым значениям по умолчанию или смотреть в другом месте или чем-то вроде той природы). В других программах Вы хотите, чтобы он пузырился длинный путь, прежде чем это обработало (например, Вы могли бы хотеть, чтобы он прервался, пока это не достигает UI, в которой точке это должно предупредить пользователя, что что-то пошло не так, как надо.
Каждый из этих случаев зависит от приложение , а не библиотека . И все же с контролируемыми исключительными ситуациями это библиотека , который принимает решение. Библиотека Java IO принимает решение, что это будет использовать контролируемые исключительные ситуации (которые сильно поощряют обрабатывать, это локально для вызова), когда в некоторых программах лучшая стратегия может быть нелокальной обработкой или никакой обработкой вообще.
Это показывает реальный дефект с контролируемыми исключительными ситуациями на практике, и это намного более фундаментально, чем поверхностное (хотя также важный) дефект, что слишком много людей запишут глупые обработчики исключений только для создания компилятора закрытым. Проблемой, которую я описываю, является проблема, даже когда испытано, добросовестные разработчики пишут программу.
Сам Андерс отвечает на этот вопрос в этом выпуске радиоподкаста по программной инженерии