NeverThrow with Result
Throwing exceptions is never a good idea, as developer we should at the very least try to handel them. Do something with them.
What problem am I trying to solve and why?
We have components that just display data, those components request data using a service.
Everything is cool, except I don’t want that request for data to ever throw an exception.
I really really don’t want to put try catch block in every component.
Why NOT and what is the alternative?
try {
const result = personService.get("CT000019");
catch(err) {
}
const result = personService.get("CT000019");
this.person = PersonDisplayModel.mapFrom(result)
Now then the PersonDisplayModel, now makes the decision what am I going to show on the screen, based off the result I just got.
The decision is moved from the component to our display model. Or component now does not do any error handeling at all. It’s nice and clean.
But what about the DisplayModel, well it’s job is still pretty easy. Most of the time it does not do anything with the error either.
The view does
< if=result.success> show the data <>
< if=result.error> show an error message, default or something else, depends on the error <>
Have we just pushed error handeling to the html template? No not a all, the template now decided what to show the user base on the result. Error Handeling, is does somewhere else. This is error display,
What is this Result
It’s a simple abstraction for our display models.
We want our components to be simple, we don’t want them to do complex error handeling, and so we don’t want to clutter our api calls with try catch blocks.
What I ask a service for some data, I never what that call to throw an exception EVER.
If our services worked that way, we would have try catch-blocks in every component, they would be every where.
I want our services to be super simple, they only have to deal with 2 states, it-worked or it-did-not.
The component then makes a very simple desig, show the data I just got back.
or show the error I just got back. it’s that easy.
When we make an API call, a request for some kind of data, we are normally in a component, and the returned data is, well going to be shown on screen.
To keep things super simple, the component only needs to know 1. Thing.
Did it work? Or did it fail?
Those are the only two states that our component should care about,
It does NOT need to know why the call faild ( that is delt with somewhere else )
Why only two states? If it succeeds, then we show the data, if it does not then we should a very much generic error message or we show nothing at all ( as the error state is handled else where ). But yeah, we normally show some error
const result = personService.get(“CT000019”);
result.success result.data result.error
So yes we do return an error, but that error is going to be the thing we show to the users, not the real 401,500 error message.
It’s a user consumable error message, made for simple folk, who don’t know tech. and that error is mostly defined by the BA’s or it’s one of the generic ones.
What about that error? What type is it? That is a good question and mostly we just want it to be a string.
Something to show our users, nothing more complex
Ahh, but now all our services must result a Result
I would our service, to state what the shape and type the data they are going to return.
That interface definition is where we can add some clear docs on what those properties represent