Axiom · light
Помилки без exceptions
Помилка — звичайний variant у типі. Вона проходить через control flow так само видимо, як success value.
Exceptions зручні, поки вам не потрібно зрозуміти всі exits функції, worst-case latency і hidden cleanup paths. Axiom обирає явні sum types.
Свої error categories
Typed errorsAxiom
1request_error:2 | bad_method3 | bad_path4 | payload_too_large(usize actual, usize limit)5 | io(io_error)6END request_error1
Окремий nominal error type.
2
Простий variant.
4
Error може нести дані, потрібні для хорошої діагностики.
5
Можна вкладати інший error ADT без втрати type safety.
Обробка на boundary
HTTP-like boundaryAxiom
1handle(request req) -> response:2 match parse(req):3 ok(command):4 RETURN execute(command)5 error(payload_too_large(actual, limit)):6 RETURN response.bad_request(text.format("{} > {}", actual, limit))7 error(_):8 RETURN response.bad_request("invalid request")2
Parser повертає result.
3
Success path.
5
Окрема реакція на конкретну проблему.
8
Решта parse errors мапляться в 400. Exception table не потрібна.
panic?
Для порушень, які справді означають bug або злам trusted boundary, система може мати окремий fatal path. Але звичайні I/O, parse, permission чи timeout ситуації не повинні маскуватися під «неочікувані» exceptions.