You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Когда мы рассматриваем какие-нибудь инструменты для связывания двух Future, например Future ожидающая запущенную на Executor'е Future, или передача результата одной в другую через OnceVar - выброс исключения одного конца на другом выглядит нормально, т.к. это все исключения пользовательского кода.
Но ошибки самих примитивов (например Abort FutureTask) смешиваются с пользовательскими, и к тому же, сами ошибки становятся неявными и выводимыми только из документации.
Возможным решение будет редизайн таких примитивов на использование Result типов в тех ситуациях, когда ошибка является ошибкой библиотеки, а не пользователя. Однако это может ударить по удобству использования из-за необходимости обрабатывать потенциально редкие случаи.
Чтобы сохранить баланс, можно воспользоваться продиктованным стандартной библиотекой правилом и ввести функции разного стиля: Foo: _ -> 'a + TryFoo: _ -> Result<'a, 'e>. Этот стиль отдает предпочтение функциям выкидывающих исключения. На практике, ошибки в примитивах Future в ряде случаев могут быть подняты до предметных, а хорошим стилем будет только пробрасывать исключения без строительства поверх них предметной логики, по этой причине я бы отдал предпочтение стилю: Foo: _ -> Result<'a, 'e>, где исключения продуцируются через композицию с Result.get.
The text was updated successfully, but these errors were encountered:
Когда мы рассматриваем какие-нибудь инструменты для связывания двух Future, например Future ожидающая запущенную на Executor'е Future, или передача результата одной в другую через OnceVar - выброс исключения одного конца на другом выглядит нормально, т.к. это все исключения пользовательского кода.
Но ошибки самих примитивов (например Abort FutureTask) смешиваются с пользовательскими, и к тому же, сами ошибки становятся неявными и выводимыми только из документации.
Возможным решение будет редизайн таких примитивов на использование Result типов в тех ситуациях, когда ошибка является ошибкой библиотеки, а не пользователя. Однако это может ударить по удобству использования из-за необходимости обрабатывать потенциально редкие случаи.
Чтобы сохранить баланс, можно воспользоваться продиктованным стандартной библиотекой правилом и ввести функции разного стиля:
Foo: _ -> 'a
+TryFoo: _ -> Result<'a, 'e>
. Этот стиль отдает предпочтение функциям выкидывающих исключения. На практике, ошибки в примитивах Future в ряде случаев могут быть подняты до предметных, а хорошим стилем будет только пробрасывать исключения без строительства поверх них предметной логики, по этой причине я бы отдал предпочтение стилю:Foo: _ -> Result<'a, 'e>
, где исключения продуцируются через композицию сResult.get
.The text was updated successfully, but these errors were encountered: