I use an object as you did at your last example. This object contains a boolean, a payload (data) and a String (message).
When the boolean is a false, either I print the message by using a System.err or it is sent to a output system (email, local logging, slack channel or whatnot).
Thanks for sharing your approach, @Abelardo — I like how you're encapsulating success and failure states using the Result pattern. Splitting into OKResult and KOResult helps make the intent really clear and could reduce boilerplate when handling errors.
Out of curiosity, have you considered making Result generic (e.g., Result<T>) to keep type safety across the payload? That way, OKResult<T> can carry typed data, and KOResult can remain focused on the error context.
Also, love the idea of a factory method to create KOResult from an exception — that definitely streamlines error wrapping.
Would be great to hear how you've structured this in larger systems — especially around propagation or chaining of results!
Since the OKResult would be the only class that would contain a payload, I would make generic OKResult with <T>, not to the base class Result (it wouldn't have a payload, only a boolean).
When an exception is generated from infra, or due to wrong code, a signal will be sent to Discord, Teams, Slack and whatnot dev channels to be alerted in any time.
For that reason is that I like the Golang approach. The returns can give yout the error + the result
I use an object as you did at your last example. This object contains a boolean, a payload (data) and a String (message).
When the boolean is a false, either I print the message by using a System.err or it is sent to a output system (email, local logging, slack channel or whatnot).
I even would create a base class called Result that it only would have a boolean flag shared with their children: OKResult and KOResult.
OKResult: boolean and a payload
KOResult: boolean, a string and a method to create a KOResult from an exception.
Thanks for sharing your approach, @Abelardo — I like how you're encapsulating success and failure states using the Result pattern. Splitting into OKResult and KOResult helps make the intent really clear and could reduce boilerplate when handling errors.
Out of curiosity, have you considered making Result generic (e.g., Result<T>) to keep type safety across the payload? That way, OKResult<T> can carry typed data, and KOResult can remain focused on the error context.
Also, love the idea of a factory method to create KOResult from an exception — that definitely streamlines error wrapping.
Would be great to hear how you've structured this in larger systems — especially around propagation or chaining of results!
Since the OKResult would be the only class that would contain a payload, I would make generic OKResult with <T>, not to the base class Result (it wouldn't have a payload, only a boolean).
When an exception is generated from infra, or due to wrong code, a signal will be sent to Discord, Teams, Slack and whatnot dev channels to be alerted in any time.