Причина дизайна why.NET не имеет концептуального (фатального)типа исключения ошибок? [закрытый]

Прежде всего, позвольте мне сказать, что это не особенно хороший вопрос для StackOverflow. Это не конкретный технический вопрос о реальном коде, а скорее поиск проектного документа-внешнего ресурса-или обоснование того, почему определенная иерархия классов была спроектирована таким образом. Ни один из них не подходит для этого.

Тем не менее, я могу сделать здесь несколько замечаний. Я думаю, что это разумное предположение, что все вовлеченные сожалеют о существовании SystemException и ApplicationException. В то время казалось хорошей идеей разделить исключения на две широкие категории: исключения, созданные самой "системой", и исключения, созданные пользователями системы. Но на практике это не является полезным различением, потому что то, что вы делаете с исключениями,-это перехват их, и при каких обстоятельствах вы хотите перехват либо (1) всех пользовательских исключений, либо (2) всех системных исключений? Никакие обстоятельства не приходят на ум.

Что это иллюстрацией здесь является не столько провал дизайна в конкретном случае - хотя, конечно, дизайн не велик - а скорее то, что при одинарном наследовании ООП вы получаете только один выстрел по "оси наследования", как это часто называют в Microsoft, и плохое решение может держаться с вами в течение длительного времени.

Теперь очень легко сказать, что в ретроспективе нам, возможно, следовало бы использовать какой-то другой поворот. Вы заметили, что в моей статье я классифицирую исключения в соответствии с тем, как они должны быть пойманы -- фатальные исключения не ловятся, потому что их ловить бесполезно, тупоголовые исключения не ловятся, потому что они на самом деле являются средствами отладки, досадные исключения должны быть пойманы из-за плохого дизайна API, а экзогенные исключения должны быть пойманы, потому что они указывают на то, что мир отличается от того, на что вы надеялись. Похоже, что здесь есть возможность лучшего поворота, где тип исключения указывает, является ли он фатальным или нет, и указывает, должен ли он быть поймали или нет. Это, конечно, не единственный возможный поворот, но он кажется правдоподобным. Можно создать статический анализатор (либо в компиляторе, либо в стороннем средстве), который проверяет правильность перехвата исключения.

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

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

Например, почему нам нужно, чтобы фатальные исключения былиисключениями ? Если это действительно так, что некоторые исключения фатальны, и это действительно так, что в некоторых редких, но критических сценариях вам нужен код для запуска, даже когда программа идет вниз из-за фатального исключения, то этот сценарий может подняться до уровня, где вы хотите синтаксис в языке, чтобы захватить эти семантики. Скажем, блок try-fatality, где код очистки только выполняется в чрезвычайно маловероятном случае фатальной ошибки. Может быть, это хорошая идея, а может быть, и нет, но суть в том, что это идея о том, чтобы поместить функцию в язык для решения проблемы , а не накапливать все больше и больше семантики на механизм, который кажется возможно, не идеально подходит для всех целей, которые он использует. Например, почему вообще существуют" тупоголовые " исключения? Существование тупоголовых исключений, таких как "эта ссылка не может быть null, вы пустышка" или "вы пытались записать файл после его закрытия, вы пустышка", на самом деле являются только исключениями, потому что они являются недостатками, в первом случае системы типов и во втором случае дизайна API. В идеале не было бы никаких тупоголовых исключений, потому что это было бы просто невозможно представить плохую программу на языке в первую очередь. Такие механизмы, как контракты кода, могут быть встроены в язык, чтобы гарантировать, что "тупоголовая" ситуация исключения будет поймана во время компиляции. Опять же, может быть, это хорошая идея, а может быть, и нет, но суть в том, что есть возможность решить эту проблему на уровне языкового дизайна, а не делать исключения нести это бремя, а затем спрашивать, как спроектировать иерархию типов, которая представляет собой тупоголовое исключение явно.