在底層開發程式的時候我常看到一個關鍵字之 IsSuccess 、 Fail 、Error 在不同的 Service 中都有出現
我就在想是因為大家的寫作都是一樣的風格嗎，後來我才知道原來是一種 Result Pattern 的設計跟導入
Result Pattern 簡單的說有兩個很重要的狀態
成功 - Result.Success(value)
失敗 - Result.Fail("reason")
C# Code for Result Pattern :
public class Result<t>
{
public bool IsSuccess { get; }
public string Error { get; }
public T Value { get; }
private Result(bool ok, T value, string error)
{
IsSuccess = ok;
Value = value;
Error = error;
}
public static Result<t> Success(T value)
=> new Result<t>(true, value, "");
public static Result<t> Fail(string error)
=> new Result<t>(false, default(T), error);
}
</t></t></t></t></t>
看起來很簡單，但是就可以讓很多錯誤訊息統一化
使用方式
C# Code:
public Result<user> CreateUser(string name, string email)
{
if (string.IsNullOrWhiteSpace(name))
return Result<user>.Fail("Name is required");
if (string.IsNullOrWhiteSpace(email))
return Result<user>.Fail("Email is required");
var user = new User(name, email);
return Result<user>.Success(user);
}
</user></user></user></user>
這些都是預期內錯誤 不需要 try/catch
呼叫端寫法更乾淨
var result = CreateUser("Donma", "");
if (!result.IsSuccess)
{
Console.WriteLine("Error: " + result.Error);
return;
}
Console.WriteLine("Created: " + result.Value.Name);
流程像在寫規格 不是一堆防呆與例外控制
遇到不可預期的錯誤怎麼辦
Result Pattern 不用來取代真正的 exception 它只處理 "預期內的錯誤"
不可預期的錯誤交給 exception
例如 DB 掛掉、Redis timeout、File I/O 堵塞、連外 API 掛掉、NullReferenceException、SDK 錯誤..等
這些才是 exception 的領域
正確方式是 Service 層用 try/catch 包住預期外錯誤 然後轉成 Result.Fail
