Здравствуйте, AndrewVK, Вы писали:
AVK>exception filter не код сокращает, а реализует некоторый сценарий, который раньше на C# был нереализуем в принципе и приходилось либо кусочки на VB писать, либо постпроцессинг IL прикручивать.
Жать в доступном не коде такие сценарии не встречаются ни разу. Если что всегда можно зделать ре-throw.
Так что соглашусь с предыдущим оратором — полезность фичи сомнительна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DarthSidius, Вы писали:
S>>Methods as well as user-defined operators and conversions can be given an expression body by use of the “lambda arrow”:
DS>И в чем кайф... эээ... сакральный смысл?
В отличии от Nemerle и F#, в C# не поддерживается концепция "все является выражением", по этому везде приходится пихать return. Фигурные скобки и return вкупе дают довольно значительный синтаксический шум. Вот авторы C# и решили подсакратить таковой позволим записывать мелкие методы в одну строку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Особенно про parameterless .ctor() в структурах. Добровольно подкладывать в язык такие грабли? Верните Хейлсберга, пожалуйста
Согласен, грабли. Но Хельсберга нужно на пенсию. Он рельный тормоз прогресса. Просто нужно фичи обсуждать публично.
Остальные (кроме конструкторов) фичи опробованы на практике и показали отличный результат. Все ворчунам нужно просто попробовать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Влезу немного с оффтопом.
S>Так это ж решается через debugdiag
А у вас есть положительный опыт использования DebugDiag для сценария "поймать конкретное managed exception и создать на него дамп"?
У меня эта шайтан-программа работала как ей заблагорассудится: то не ловила ничего, то ловила что-то левое, то ловила ровно то, что просили, ... но как это повторить гарантированно в следующий заход я так и не понял. Просидев несколько дней в попытке понять логику и постигнуть дзен, я с горяча полез во внутренности, и когда осознал что вся логика фильтрации нужных событий лежит в сгенерированном программой-конфигуратором VBScript-файле, то от горя и ужаса спрятался под рабочий стол...
В общем, я не исключаю, что где-то я чего-то недопонял, но попытки разобраться оставил до лучших времен, как и использование DebugDiag на продакшене.
А как у вас?
Здравствуйте, Михаил Романов, Вы писали:
МР>А у вас есть положительный опыт использования DebugDiag для сценария "поймать конкретное managed exception и создать на него дамп"?
Всего пару раз, обычно через remote debug, трассировку, или вообще локально воспроизводилось. Там главное нужный тип исключения выставить. С ETW только игрался, но показалось намного проще.
Здравствуйте, VladD2, Вы писали:
VD>Жать в доступном не коде такие сценарии не встречаются ни разу.
Ну потому что у тебя совсем другая область деятельности, не связанная с серверным софтом. А у меня встречалось, Sinix наверняка даже догадается где.
VD> Если что всегда можно зделать ре-throw.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты просто не в курсе. Андерс, после ковыряния с JS/TS, сильно поменял свою точку зрения, в том числе на structural typing, PM и not-nullable types.
Я в курсе того сколько ему еще ковырять.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В отличии от Nemerle и F#, в C# не поддерживается концепция "все является выражением", по этому везде приходится пихать return. Фигурные скобки и return вкупе дают довольно значительный синтаксический шум. Вот авторы C# и решили подсакратить таковой позволим записывать мелкие методы в одну строку.
Всем:
Ок, у кого много настолько мелких методов в проекте?
Просто выглядит как мышинная возня. Ну да ладно — они все силы бросили на Рослин.
Здравствуйте, DarthSidius, Вы писали:
DS>Ок, у кого много настолько мелких методов в проекте?
Вообще-то их хватает обычно. В Немерле мы чаще такие локальными функциями оформляем, но за неимением горничной... и это не плохо.
Кстати, локальные функции — офигительно удобная вещь! Я бы очень советовал команде шарпа взять ее на вооружение.
DS>Просто выглядит как мышинная возня. Ну да ладно — они все силы бросили на Рослин.
Так и есть. В этом релизе делаются мелкие фичи которые стало просто реализовать благодаря переходу на Розлин. Они переводят на управляемый код все... от компилятора, до рефакторингов. Поверь, работы там море. Особенно с их подходами к разработке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinix, Вы писали:
S>Всего пару раз, обычно через remote debug, трассировку, или вообще локально воспроизводилось. Там главное нужный тип исключения выставить. С ETW только игрался, но показалось намного проще.
Понял, спасибо.
Жаль, конечно. Чисто теоретически инструмент выглядит интересным и полезным.
Тем более, что с прода баги идут косяками и чисто логами обойтись не удается...
Ну и на ETW я тоже все собираюсь посмотреть попристальнее. Но как обычно, времени не хватает
Здравствуйте, VladD2, Вы писали:
AVK>>exception filter не код сокращает, а реализует некоторый сценарий, который раньше на C# был нереализуем в принципе и приходилось либо кусочки на VB писать, либо постпроцессинг IL прикручивать.
VD>Жать в доступном не коде такие сценарии не встречаются ни разу. Если что всегда можно зделать ре-throw. VD>Так что соглашусь с предыдущим оратором — полезность фичи сомнительна.
В нашем вот проекте (как и во многих проектах на прошлых работах) будет очень полезна, и вот почему — архитектура у нас такая многослойная, как лук и на границе между слоями как правило имеются методы
try {
// Что-то делаем на более низком уровне
} catch(Exception ex) {
Log(ex);
throw;
}
и вот когда исключение случается где-нить в глубине, сидя в отладчике приходится прыгать по всем этим throw; так как отладчику приказано вываливаться на каждый бросок. Это очень печально, особенно когда в глубоких потрохах кто-то что-то поломает вдруг и на какое-то время кусок, с которым нужно работать, является таким нестабильным.
Ругать подобные архитектуры даже не начинайте, не в этом дело, а в том, что так вот уже есть и надо как-то с этим жить. Принципиально переписать сложно. а заменить подобное безобразие фильтром с логированием самое оно.
Здравствуйте, DarthSidius, Вы писали:
DS>Просто выглядит как мышинная возня. Ну да ладно — они все силы бросили на Рослин.
Сначала это, потом будет Semicolon operator: (var x = Foo(); Write(x); x * x) .
Ну и апофеозом будет объединение этого дела:
public int F(int a) =>
(
Console.WriteLine(a);
a + 1
)
Здравствуйте, xy012111, Вы писали:
X>В нашем вот проекте (как и во многих проектах на прошлых работах) будет очень полезна, и вот почему — архитектура у нас такая многослойная, как лук и на границе между слоями как правило имеются методы X>
X>try {
X> // Что-то делаем на более низком уровне
X>} catch(Exception ex) {
X> Log(ex);
X> throw;
X>}
X>
И причем тут фильтры?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Где можно посмотреть таблицу с разницей библиотек классов .NET и .NET Core? Какие пространства имён, классы и методы из .NET не входят в Core? Какие добавились по сравнению с .NET 4.5.1?
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, DarthSidius, Вы писали:
DS>>Просто выглядит как мышинная возня. Ну да ладно — они все силы бросили на Рослин. _NN>Сначала это, потом будет Semicolon operator: (var x = Foo(); Write(x); x * x) . _NN>Ну и апофеозом будет объединение этого дела:
_NN>
_NN>public int F(int a) =>
_NN>(
_NN> Console.WriteLine(a);
_NN> a + 1
_NN>)
_NN>
Здравствуйте, Qbit86, Вы писали:
S>>В официальном блоге появилось описание текущего положения дел с C#6.
Q>Где можно посмотреть таблицу с разницей библиотек классов .NET и .NET Core? Какие пространства имён, классы и методы из .NET не входят в Core? Какие добавились по сравнению с .NET 4.5.1?
В основном, только слухи из разных блогов и выступлений. Есть немного подробностей, самое полезное:
NET Core is very much in the same family as the .NET Framework. For example, the SIMD and Immutable Collections NuGet packages work on both the .NET Framework and .NET Core, by design. You can expect that most aspects of your development experience will be unchanged when targeting .NET Core.
...
ASP.NET 5 is the first workload that has adopted .NET Core. ASP.NET 5 runs on both the .NET Framework and .NET Core.
...
.NET Core has two major components. It includes a small runtime that is built from the same codebase as the .NET Framework CLR. The .NET Core runtime includes the same GC and JIT (RyuJIT), but doesn’t include features like Application Domains or Code Access Security. The runtime is delivered via NuGet, as part of the ASP.NET 5 core package.
.NET Core also includes the base class libraries. These libraries are largely the same code as the .NET Framework class libraries, but have been factored (removal of dependencies) to enable us to ship a smaller set of libraries. These libraries are shipped as System.* NuGet packages on NuGet.org.
Не, серьёзно, зачем портить язык, добавляя 100500й способ сделать то же самое, только на пару символов короче? Не, для write-only кода, который никогда читать не будут, а сразу выбросят и перепишут, оно может и удобно.
Для нормального человека в чём кайф ловить разницу между
public int F(int a) =>
(
Console.WriteLine(a);
a + 1
)
// иpublic int F(int a)
{
Console.WriteLine(a);
return a + 1;
}
?
A> Ну возвращать последнее выражение видимо уже невозможно, поведение сильно поменяет. А так конечно локальных функций нормальных не хватает иногда.
Верните Хейлсберга, пожалуйста 
