Комментарии 7
На картинке настоящий ящик с инструментами?
Да, созданный мастером по изготовлению пианино и фортепиано Генри Стадли. Очень функциональный, подходящий как для грубых работ по дереву, так и тонкой настройки. Оригинал
Ещё бывает полезно предоставлять варианты метода с выбрасыванием исключений и с кодом ошибки, грубо говоря:
Ещё желательно позаботиться об обработке unhandled exceptions (отовсюду, в шарпах это значит, что надо ловить и AppDomain.CurrentDomain.UnhandledException, и TaskScheduler.UnobservedTaskException, и Dispatcher.UnhandledException) или хотя бы предоставить в SDK такую возможность, это несложно и очень упрощает жизнь.
Опять же, если пишете на C# — надо продумать всё, что связано с контекстом, и определить правила, которых вы будете придерживаться. Например, мы у себя не используем ConfigureAwait(false) по ряду причин, и для гарантированного переключения контекста у нас есть специальная небольшая структура.
Также, если у вас есть асинхронный код (а это скорее всего так), и вы его передаёте в диспетчер или Task.Run — лучше сразу позаботиться о том, чтобы в случае чего вы получили грамотный call stack, а не обрывок.
Если у вас большой solution, удобно использовать файл Directory.Build.props для задания свойств и действий, которые будут применяться ко всем проектам — например, вы можете через этот файл подключить один AssemblyInfo.cs ко всем проектам, а также настроить CodeAnalysis и StyleCop в одном месте. Если надо будет на время отключить стайлкоп — достаточно поправить один файл, то же касается версий и т.д.
public CoolResult DoSomethingCool(...); // кидает исключение
public bool TryDoSomethingCool(..., out CoolResult result); // возвращает флаг
Ещё желательно позаботиться об обработке unhandled exceptions (отовсюду, в шарпах это значит, что надо ловить и AppDomain.CurrentDomain.UnhandledException, и TaskScheduler.UnobservedTaskException, и Dispatcher.UnhandledException) или хотя бы предоставить в SDK такую возможность, это несложно и очень упрощает жизнь.
Опять же, если пишете на C# — надо продумать всё, что связано с контекстом, и определить правила, которых вы будете придерживаться. Например, мы у себя не используем ConfigureAwait(false) по ряду причин, и для гарантированного переключения контекста у нас есть специальная небольшая структура.
Также, если у вас есть асинхронный код (а это скорее всего так), и вы его передаёте в диспетчер или Task.Run — лучше сразу позаботиться о том, чтобы в случае чего вы получили грамотный call stack, а не обрывок.
Если у вас большой solution, удобно использовать файл Directory.Build.props для задания свойств и действий, которые будут применяться ко всем проектам — например, вы можете через этот файл подключить один AssemblyInfo.cs ко всем проектам, а также настроить CodeAnalysis и StyleCop в одном месте. Если надо будет на время отключить стайлкоп — достаточно поправить один файл, то же касается версий и т.д.
Очень содержательно, спасибо!
Про Unhandled и Aggregate Exceptions стоило упомянуть, спасибо, что дополнили. Про управление задачами и контекстами — это касается всех многопоточных приложений, в статье же речь только о SDK, но тут тоже очень в тему. Про комплексную сборку тоже очень дельный совет.
Про Unhandled и Aggregate Exceptions стоило упомянуть, спасибо, что дополнили. Про управление задачами и контекстами — это касается всех многопоточных приложений, в статье же речь только о SDK, но тут тоже очень в тему. Про комплексную сборку тоже очень дельный совет.
Да, но дело в том, что если вы пишете библиотечный код, то обычно не можете знать, в каком контексте он будет вызван. Обычная рекомендация — добавлять везде .ConfigureAwait(false), но эта конструкция семантически некорректна, и очень легко забыть написать её в каком-то одном месте, и получить дедлок у клиента.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SDK тебе, SDK мне, SDK всем! Как делать SDK и зачем это нужно