"не решенная проблема", ну имхо, найдутся ещё люди которые бы такое хотели. И эта фича прекрасно ложится в dotnet. Думаю, глупо отрицать ее полезность, это не мной придумано.
xml-дока выглядит похоже на то, что нужно, на она имеет "рекомендательный" эффект. На уровне синтаксиса компилятор будет кидать ошибку. И нет варианта не обработать исключение.
(вероятно, вы имели в виду "Вообще говоря не обязан")
см. коммент выше, я хочу чтобы был обязан, это просто моя хотелка, т.к. я не люблю магию. Я хочу видеть с чем я имею дело на уровне синтаксиса, а не документации/ исходников/ или еще хуже, узнавать в рантайме.
2) не вижу проблемы выносить исключения в абстракцию, и с полиморфизмом ничего не случится
Вы пытаетесь спорить с реальностью, исключения в контрактах УЖЕ существуют, я лишь говорю, что такго не хватает в C#, посмотрите как это сделано в java
Имхо, исключения как раз таки тот единственный механизм который помогает тебе прокидывать информацию вверх по стеку, если текущий метод не знает, что с этим делать, то наверху разберутся. По хорошему, каждый метод ОБЯЗАН явным образом так или иначе обработать исключение, прокинуть наверх, логирование, или метод сам разбирается с исключением, если может.
Проблема в том, что ты не знаешь какие исключения выкинет метод, пока не загуглишь/посмотришь код/выяснишь в рантайме, по факту можно на уровне синтаксиса это обозначить
Данные можно передавать, просто кастомное исключение с со своими полями какие нужно
Обработка ошибок как будто бы не решенная проблема. Подход Java с указанием генерируемых исключений мне нравится больше, но да, бойлерплейта много будет. Но, имхо, лучше много кода (добавленного через сниппеты зачастую), чем выяснять в рантайме или через исходники или доку какие там могут быть в методе исключения
"не решенная проблема", ну имхо, найдутся ещё люди которые бы такое хотели. И эта фича прекрасно ложится в dotnet. Думаю, глупо отрицать ее полезность, это не мной придумано.
xml-дока выглядит похоже на то, что нужно, на она имеет "рекомендательный" эффект. На уровне синтаксиса компилятор будет кидать ошибку. И нет варианта не обработать исключение.
Ну, камон ДЕЛЕГАТ, он как раз определяет сигнатуру метода (контракт), ничего не мешает там же определять исключения
(вероятно, вы имели в виду "Вообще говоря не обязан")
см. коммент выше, я хочу чтобы был обязан, это просто моя хотелка, т.к. я не люблю магию. Я хочу видеть с чем я имею дело на уровне синтаксиса, а не документации/ исходников/ или еще хуже, узнавать в рантайме.
1) а я хочу чтобы являлось
2) не вижу проблемы выносить исключения в абстракцию, и с полиморфизмом ничего не случится
Вы пытаетесь спорить с реальностью, исключения в контрактах УЖЕ существуют, я лишь говорю, что такго не хватает в C#, посмотрите как это сделано в java
Имхо, исключения как раз таки тот единственный механизм который помогает тебе прокидывать информацию вверх по стеку, если текущий метод не знает, что с этим делать, то наверху разберутся. По хорошему, каждый метод ОБЯЗАН явным образом так или иначе обработать исключение, прокинуть наверх, логирование, или метод сам разбирается с исключением, если может.
Проблема в том, что ты не знаешь какие исключения выкинет метод, пока не загуглишь/посмотришь код/выяснишь в рантайме, по факту можно на уровне синтаксиса это обозначить
Данные можно передавать, просто кастомное исключение с со своими полями какие нужно
Обработка ошибок как будто бы не решенная проблема. Подход Java с указанием генерируемых исключений мне нравится больше, но да, бойлерплейта много будет. Но, имхо, лучше много кода (добавленного через сниппеты зачастую), чем выяснять в рантайме или через исходники или доку какие там могут быть в методе исключения