#API exception handling
1 messages · Page 1 of 1 (latest)
#help-development message
As I understand, you mean that at the end, there should not be any exceptions to be dealt with by the api user?
What about situations where there is something like a number-formatting exception? It means that the code can not propperly run, as information is lacking.
wait I will continue this error handling thing in a bit
need to go and handle some errands
Ok, sorry, I'm back, just got something to eat.
But I'll be gone in about 30 mins again
When you have time Conclure, or whoever is interested or has an opinion to share, I'd like to still have this convo, since I do want to learn more about this topic. Even if it is fairly subjective... probably.
@lusty marsh Sorry to ping you, but I'm still very interested
Oh yes
So the discussion was about result objects contra raising exceptions in the layer of api?
Yea.
Is it better to return something like an Optional<> or to just return the value itself, but raising an Exception in the case of an error.
After some thaught, I came to the conclusion that raising an exception would be better, then many different errors can be covered via different exceptions, giving a far better description of the underlying issue. Not only that, but then you actually get the value returned, instead of an empty Optional, in which case you don't know why it was returned empty in the first place.