try
{
// ...
}
catch
{
| ArgumentException => Console.WriteLine("вы подумали что ловиться будет только ArgumentException, а на самом деле ловится все подряд");
// хорошо что хоть варнинг есть, правда непонятный
}
C>try
C>{
C> // ...
C>}
C>catch
C>{
C> | ArgumentException => Console.WriteLine("вы подумали что ловиться будет только ArgumentException, а на самом деле ловится все подряд");
C> // хорошо что хоть варнинг есть, правда непонятный
C>}
C>
Мне например неочеидно, почему надо думать, что ловиться будет только ArgumentException Вроде как очевидно, что должно ловиться всё подряд.
Здравствуйте, _NN_, Вы писали:
_NN>За что боролись на то и напоролись. _NN>Надо придумать как правильно решить эту проблему, чтобы не было неоднозначностей.
Я думаю надо как в match сделать если хотим ловить тип то пишем с большой, если переменная то с маленькой, тогда неоднозначностей не будет. Если написал с маленькой значит должен использовать переменную, и выглядит по человечески, как в матче, если не использовал будет варнинг, а выражение типа ArgumentException считать проверкой ловли исключения типа только ArgumentException, вариант | _ is ArgumentException считать эквивалентным.
Здравствуйте, CodingUnit, Вы писали:
CU>Здравствуйте, _NN_, Вы писали:
_NN>>За что боролись на то и напоролись. _NN>>Надо придумать как правильно решить эту проблему, чтобы не было неоднозначностей.
CU>Я думаю надо как в match сделать если хотим ловить тип то пишем с большой, если переменная то с маленькой, тогда неоднозначностей не будет. Если написал с маленькой значит должен использовать переменную, и выглядит по человечески, как в матче, если не использовал будет варнинг, а выражение типа ArgumentException считать проверкой ловли исключения типа только ArgumentException, вариант | _ is ArgumentException считать эквивалентным.
Тогда конр-вопрос.
Дан тип с маленькой буквы, и хотим переменную с большой.
Как это будет выглядеть ?
Предлагается такой вариант не поддерживать ?
Здравствуйте, _NN_, Вы писали:
_NN>Тогда конр-вопрос. _NN>Дан тип с маленькой буквы, и хотим переменную с большой. _NN>Как это будет выглядеть ? _NN>Предлагается такой вариант не поддерживать ?
Также как с матчем, если хотим матчить тип с маленькой, то пишем
_ is small_type_name
переменные с большой нет смысла поддерживать, я не знаю кто использует это в матче, в крайнем случае можно так _ as A, это работает в матче, но портит представление кода большая буква, потому что они в основном используются для типов.
Здравствуйте, _NN_, Вы писали:
_NN>Тогда конр-вопрос. _NN>Дан тип с маленькой буквы, и хотим переменную с большой. _NN>Как это будет выглядеть ? _NN>Предлагается такой вариант не поддерживать ?
Главное в предложенном варианте что это уберет неоднозначность, и даст предсказуемое поведение | a — отлов всех типов в переменную если не используется варнинг, | A — отлов типа также как и _ is A. Таким образом, надо в компиляторе сделать поддержку | A как отлов исключений типа A, я думаю это можно сделать просто переписывая выражение с большой буквы | A в | _ is A, тогда грабли обойдем.
Здравствуйте, CodingUnit, Вы писали:
CU>переменные с большой нет смысла поддерживать, я не знаю кто использует это в матче, в крайнем случае можно так _ as A, это работает в матче, но портит представление кода большая буква, потому что они в основном используются для типов.
Мало ли кто-то хочет.
Конвенция кода такая.
Итого:
1. Большая буква — всегда тип
2. Маленькая буква — всегда переменная
3. Гарантированно тип: _ is Type
4. Гарантированно переменная: _ as Var
В таком случае почему бы не считать ошибкой использование типов вместо переменной и наоборот в случае 1 и 2 ?
Зачем предупреждение ?
_NN>Конвенция кода такая.
_NN>Итого: _NN>1. Большая буква — всегда тип _NN>2. Маленькая буква — всегда переменная _NN>3. Гарантированно тип: _ is Type _NN>4. Гарантированно переменная: _ as Var
_NN>В таком случае почему бы не считать ошибкой использование типов вместо переменной и наоборот в случае 1 и 2 ? _NN>Зачем предупреждение ?
Конвенция кода на сегодняшний момент в матче именно такая, предупреждение если матчится переменная в пункте 2, как еще выяснить что пользователь хотел там тип? В пункте один естественно должно быть сообщение об ошибке если нет такого типа, аналогично применению _ is A. Во всех вариантах поведение как в матче мне нравится, это понятно, варнинг никогда не напрягал в матче в случае переменных, кто его знает что хотел пользователь сказать переменную или тип, матчится переменная и все и это будет сразу видно в студии с подчеркиванием, привыкнуть к этому проще всего, кто программирует обычные match конструкции. Меня наоборот всегда раздражало что синтаксис catch отличается и ограничен по сравнению с match.
Здравствуйте, CodingUnit, Вы писали:
CU>Здравствуйте, _NN_, Вы писали:
_NN>>Конвенция кода такая.
_NN>>Итого: _NN>>1. Большая буква — всегда тип _NN>>2. Маленькая буква — всегда переменная _NN>>3. Гарантированно тип: _ is Type _NN>>4. Гарантированно переменная: _ as Var
_NN>>В таком случае почему бы не считать ошибкой использование типов вместо переменной и наоборот в случае 1 и 2 ? _NN>>Зачем предупреждение ?
CU>Конвенция кода на сегодняшний момент в матче именно такая, предупреждение если матчится переменная в пункте 2, как еще выяснить что пользователь хотел там тип? В пункте один естественно должно быть сообщение об ошибке если нет такого типа, аналогично применению _ is A. Во всех вариантах поведение как в матче мне нравится, это понятно, варнинг никогда не напрягал в матче в случае переменных, кто его знает что хотел пользователь сказать переменную или тип, матчится переменная и все и это будет сразу видно в студии с подчеркиванием, привыкнуть к этому проще всего, кто программирует обычные match конструкции. Меня наоборот всегда раздражало что синтаксис catch отличается и ограничен по сравнению с match.
Тогда на мой взгляд лучше давать по рукам изначально.
Здравствуйте, Ikemefula, Вы писали:
I>Мне например неочеидно, почему надо думать, что ловиться будет только ArgumentException Вроде как очевидно, что должно ловиться всё подряд.
…даже не буду спрашивать. Потому что в аналогичном match(e) { ArgumentException => () } будет матчится только исключение соответствующего типа.
Здравствуйте, CodingUnit, Вы писали:
CU>Здравствуйте, _NN_, Вы писали:
_NN>>Также как и предупреждение выводить , только вместо предупреждение вывести ошибку
CU>Ошибку что переменная неиспользуется? Не кажется это слишком?
Секунду , что-то я запутался.
С Большой буквы всегда тип , с маленькой всегда переменная, так ведь ?
Тогда неоднозначностей нет и никаких лишних предупреждений тоже нет.
Я поддерживаю такой вариант.
Устроим голосование ?
_NN>Секунду , что-то я запутался. _NN>С Большой буквы всегда тип , с маленькой всегда переменная, так ведь ? _NN>Тогда неоднозначностей нет и никаких лишних предупреждений тоже нет.
_NN>Я поддерживаю такой вариант. _NN>Устроим голосование ?
Неоднозначностей нет, нижний регистр переменная, верхний регистр тип, тогда в окружающем коде появляются соответствующие ошибки и предупреждения, которые уместны. Если пользователь ввел слово в нижнем регистре | a, но понимал это как тип, то соответствующее слово будет подчеркнуто поскольку он не будет использовать переменную. Если будет написано | A но интерпретируя что это должно матчить любое исключение в переменную A то получит ошибку что не найден соответствующий тип. Я думаю такое поведение предсказуемо и уже давно работает с матч конструкциями, уберет неоднозначность со типами исключений .net и сделает большую стройность в языке, catch будет больше походить на match. Я поддерживаю такой вариант.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, catbert, Вы писали:
_NN>За что боролись на то и напоролись. _NN>Надо придумать как правильно решить эту проблему, чтобы не было неоднозначностей.
У Nemerle синтаксис catch-блока похож на match, но совершенно другой, его очевидно не сильно продумывали. По-хорошему нужно переписать там все, чтобы семантика match-а соблюдалась ближе. В конце концов, можно использовать CLR-овские guard-ы.
C>try
C>{
C> // ...
C>}
C>catch
C>{
C> | ArgumentException => Console.WriteLine("вы подумали что ловиться будет только ArgumentException, а на самом деле ловится все подряд");
C> // хорошо что хоть варнинг есть, правда непонятный
C>}
C>
Сделал пулл-реквест исправляющий ошибку, в соответствии с договоренностью в этой теме.
Вроде как очевидно, что должно ловиться всё подряд.
