Simulating Return Type Inference in C#

C# Functional Programming Language Extensions

Я принес вам решение проблемы с исключениями в C#. Но вам не понравится

я трачу кучу времени на то, чтобы решить, как быть, если что-то идёт не по плану

Если что-то идёт не по плану — кидайте исключения. Всегда.
А описанная в статье проблема — это возвращение ожидаемого (планового) ошибочного результата.

Для себя решил так:
Исключения — только для исключительных ситуаций. Как только появляется поведение, не предусмотренное ходом выполнения программы — кидаем исключение.
Для всего остального — монады из C# Functional Programming Language Extensions
Там есть и Option<>, и Either<,>, и куча всего другого, что позволяет не изобретать велосипед.
При этом не вижу ничего плохого возвращать хоть null, хоть самописный класс, если это позволяет определять ожидаемое поведение и обрабатывать соответствующие ошибки (null/не null в некоторых случаях может быть аналогичен Option<>, в самописных классах обычно делают поля и для результата, и для ошибки, что аналогично Either<,>).

В примере с условным чтением файла:
Если мы ожидаем, что файл всегда должен существовать и без этого ничего дальше работать не может, то кидаем исключение. Как правило, это файлы сборок, конфигурационные файлы и другие файлы, без которых работа приложения невозможна.
Если мы допускаем, что файла может не быть, то либо Option<> (если причина нас не интересует), либо Either<,>. Например, загружаемые пользователем файлы, временные файлы, сгенерированные программой

В основе «классического» подхода с собственными исключениям лежит отсутствие в первых версиях языка LINQ, лямбда-выражений и другой функциональщины. Поэтому и рекомендовался подход с созданием собственных исключений (т.е. при ожидании отсутствия файла нужно на самом деле кидать своё исключение, а не FileNotFoundException). С развитием языка появилось больше функциональных возможностей, в т.ч. и для использования монад. Поменялась и «классика» — теперь нужно просто брать лучшее у каждого из подходов.

«Подводные камни» простой электронной подписи

Вы правы во всём, кроме того, что я не прав. Я недостаточно точно и подробно выразился, из-за чего был неправильно понят.

Мой комментарий следует читать так:

В этом случае вы отправляете уже не самоподписанный запрос, а подписываете <самоподписанный> запрос закрытым ключом с действующим сертификатом.

Это как раз ваш второй вариант (подписание нового самоподписанного запроса закрытым ключом с действующим сертификатом и отправка полученной PKCS#7-структуры). Безусловно, никто не выпускает сертификат когда открытый ключ подписи запроса не соответствует закрытому ключу (что является тонким намёком на прочтение слово самоподписанный между строк, но никак не умоляет моих грехов). Механизм подписи уже подписанного запроса широко используется (например, в КриптоПро УЦ как одобрение на выпуск сертификата оператором).

Хотел бы добавить к соответствию терминов, что в англоязычной среде разница между ЭП-ЭЦП-ЦП более явная, чем у нас. Так, электронная подпись (electronic signature) — более общий термин, включающий любые данные в электронном виде, логически связанные с другими данными в электронном виде и использующиеся подписантом для подписи (например, биометрические данные), в то время как цифровая подпись (digital signature) — более узкий и являющийся подмножеством электронной подписи термин, означающий подпись, созданную с помощью криптографии.

«Подводные камни» простой электронной подписи

Удалённое продление (или перевыпуск сертификата) — это традиционная возможность, предоставляемая УЦ.
В этом случае вы отправляете уже не самоподписанный запрос, а подписываете запрос закрытым ключом с действующим сертификатом. По истечении срока действия сертификата такая процедура невозможна.

«Подводные камни» простой электронной подписи

Термин «сторона пользователя» в законе не определён. В моём понимании это личный токен, доступ к ключам которого имеет только пользователь. Можно придти с ним в УЦ и сгенерировать ключи там, но системы УЦ доступа к закрытому ключу иметь не должны, т.к. статьи 9 и 10 федерального закона №63-ФЗ гласят:

Статья 9. Использование простой электронной подписи

…
2. Нормативные правовые акты и (или) соглашения между участниками электронного взаимодействия, устанавливающие случаи признания электронных документов, подписанных простой электронной подписью, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать, в частности:
…
2) обязанность лица, создающего и (или) использующего ключ простой электронной подписи, соблюдать его конфиденциальность.
…

Статья 10. Обязанности участников электронного взаимодействия при использовании усиленных электронных подписей

При использовании усиленных электронных подписей участники электронного взаимодействия обязаны:
1) обеспечивать конфиденциальность ключей электронных подписей, в частности не допускать использование принадлежащих им ключей электронных подписей без их согласия;
…
3) не использовать ключ электронной подписи при наличии оснований полагать, что конфиденциальность данного ключа нарушена;

Получение доступа к закрытому ключу третьими лицами (в том числе самим УЦ) является нарушением конфиденциальности.

«Подводные камни» простой электронной подписи

Ключевая пара (открытый ключ и закрытый ключ) должны генерироваться на стороне пользователя. В УЦ отправляется запрос на сертификат. Запрос содержит открытый ключ и подписывается соответствующим ему закрытым ключом (тем самым подтверждается подлинность владения ключевой парой). На основании этого запроса УЦ выпускает сертификат, который устанавливает связь между ключевой парой и конкретным лицом.