Comments 15
Хоть бы и так, а то что всё F#, да F#:
[RequiredResult]
enum PostBoostInteractionKeyDecodingError
{
InvalidKeyFormat,
MismatchingUser,
MismatchingIdentity,
}
...
interface IPostBoostInteractionKeyDecoder
{
Result<PostBoostInteractionSource, PostBoostInteractionKeyDecodingError> DecodeInteractionKey(EntityId<SimpleUserProfile> profileId, BoostTarget target, string interactionKey);
}
...
[RequiredResult]
public enum RegisterBoostedPostInteractionResult
{
Success,
MissingOrInactiveBoost,
AlreadyVisited,
PaymentFailed,
}
...
interface IPostBoostInteractionTracker
{
RegisterBoostedPostInteractionResult RegisterInteraction(EntityId<SimpleUserProfile> profileId, PostBoostInteractionSource source, PostBoostInteractionType type);
}
...
bool RegisterInteraction(string interactionKey, EntityId<SimpleUserProfile> profileId, BoostTarget target, PostBoostInteractionType interactionType)
=> _interactionKeyDecoder.DecodeInteractionKey(profileId, target, interactionKey)
.And(source => _interactionTracker.RegisterInteraction(profileId, source, interactionType))
.And(registerResult => registerResult == RegisterBoostedPostInteractionResult.Success)
.Unwrap(false);
А
EntityId
свой не покажете? Хочется со своим сравнить.gist.github.com/onyxmaster/9c9ee7dcab78205de441189e45b01134
EntityId.FromString/ToString думаю можно не приводить.
Когда-то был 128-битный, чтобы можно было генерировать без использования внешнего состояния (а-ля Snowflake), но потом от этой схемы отказались.
EntityId.FromString/ToString думаю можно не приводить.
Когда-то был 128-битный, чтобы можно было генерировать без использования внешнего состояния (а-ля Snowflake), но потом от этой схемы отказались.
Мне кажется у вас спойлер коротковат. Думаю многие пользователи мобильного интернета не оценят три картинки на превью статьи.
Замечательная статья, Спасибо!
С монадами не работал, но общая идея и примеры понравились (даже картинки тематические не поленились нарисовать :) ), написано по делу, несложно разобраться.
Появилось желание разобраться в F# ;)
С монадами не работал, но общая идея и примеры понравились (даже картинки тематические не поленились нарисовать :) ), написано по делу, несложно разобраться.
Появилось желание разобраться в F# ;)
Получился эквивалент кода на исключениях.
Даже проблемы с конвертацией ошибок на границах абстракций те же.
В плюс идет проброс ошибки без раскрутки стека, в минус — не знаю как на F#, но на C# такой код умучаешься отлаживать.
Даже проблемы с конвертацией ошибок на границах абстракций те же.
В плюс идет проброс ошибки без раскрутки стека, в минус — не знаю как на F#, но на C# такой код умучаешься отлаживать.
В плюсы ещё список всех Failure (как с checked exceptions). Минусы масштабируемости как с checked exceptions:) Для валидация ИМХО такой подход хорошо работает. Для всего приложение — на любителя.
В плюсы ещё список всех Failure (как с checked exceptions).
Вот это я как раз в плюсы занести не могу — слишком уж жесткий получается контракт, причем за счет фиксации на побочных путях, имеющих не самое прямое отношение к основной решаемой задаче.
Кстати, на F# же вроде есть аналог do-нотации, почему бы не использовать его?
Кстати, на F# же вроде есть аналог do-нотации, почему бы не использовать его?
Можно. Скотт пояснил, что не использовал их, чтобы «сработало» его маркетинговое обещание про то, что код с обработкой ошибок и без будет одинаковым:) Более того, Mark Seemann нечто подобное уже предложил уже в своем блоге. Правда там Either и Async. Идея немного другая, но сделано как раз с помощью computation expressions.
Кажется, автор переизобрел unix-пайпы и stderr.
Ну вот, сначала обработку ошибок добавляют не меняя код, потом ассинхронность, потом транзакционность. Зачем лишать программиста удовольствия код поредактировать?
Sign up to leave a comment.
Железнодорожно-ориентированное программирование. Обработка ошибок в функциональном стиле