Раньше я писал Exception'ы, выстраивал цепочки и радовался жизни, перехватывая их через самописный Middleware и оборачивая их в ProblemDetails. А затем я посмотрел сколько RPS теряю на throw new Exception("Hello world!") и мне стало максимально грустно. Терять в 10 раз RPS, только потому что обработка исключения действительно дорогое удовольствие, это очень грустно.
Сначала, я пробовал разные методики, например, которые мне встречались в PInvoke. Если null — то нету, если есть — значит есть. Отсюда и *Default() пошли. Но этого было мало. Логика росла, валидация убивала смысл жизни, а затем я пришел к такому простенькому интерфейсу, а там уже реализация, которая принимала все в себя через конструктор new InteractionResult(result/errors/exception/validationResult)
public interface IInteractionResult
{
bool Succeeded { get; }
IDictionary<string, string[]> Errors { get; }
}
public interface IInteractionResult<TResult> : IInteractionResult
where TResult : class
{
TResult Result { get; }
}
Честно подсмотренная практика у ASP.NET Core Identity. И неважно что здесь она Maybe, в комментариях выше отсыллки Either. Важно, что она решает проблемы и достаточно легко реализуемая конструкция.
Exception'ы это как уровень Error или Critical (нет) в вашем инструменте логирования. Если вы ожидаете, что пользователь может вам недодать информации — это Warning. Скажите вежливо, что вы не можете это сделать, объяснив вежливо почему. Но если произошло действительно что-то необратимое/необрабатываемое, тут уже стоит выкинуть соотвествующий Exception.
Раньше я писал Exception'ы, выстраивал цепочки и радовался жизни, перехватывая их через самописный Middleware и оборачивая их в ProblemDetails. А затем я посмотрел сколько RPS теряю на
throw new Exception("Hello world!")и мне стало максимально грустно. Терять в 10 раз RPS, только потому что обработка исключения действительно дорогое удовольствие, это очень грустно.Сначала, я пробовал разные методики, например, которые мне встречались в PInvoke. Если null — то нету, если есть — значит есть. Отсюда и
*Default()пошли. Но этого было мало. Логика росла, валидация убивала смысл жизни, а затем я пришел к такому простенькому интерфейсу, а там уже реализация, которая принимала все в себя через конструкторnew InteractionResult(result/errors/exception/validationResult)Честно подсмотренная практика у ASP.NET Core Identity. И неважно что здесь она
Maybe, в комментариях выше отсыллкиEither. Важно, что она решает проблемы и достаточно легко реализуемая конструкция.Exception'ы это как уровень Error или Critical (нет) в вашем инструменте логирования. Если вы ожидаете, что пользователь может вам недодать информации — это Warning. Скажите вежливо, что вы не можете это сделать, объяснив вежливо почему. Но если произошло действительно что-то необратимое/необрабатываемое, тут уже стоит выкинуть соотвествующий Exception.
Ой йо. Мб лучше олимпиады навернете, вместо колледжа? Или летнюю компьютерную школу?
https://ditp.ifmo.ru/ru/page/18883/lksh.htm
Стоит вспомнить мобильную версию, которая работает стабильно и даже без «относительно оригинала». При этом практически ничего не урезав