#API exception handling

1 messages · Page 1 of 1 (latest)

tidal silo
#

#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.

lusty marsh
#

wait I will continue this error handling thing in a bit

#

need to go and handle some errands

tidal silo
#

Ok, sorry, I'm back, just got something to eat.
But I'll be gone in about 30 mins again

tidal silo
#

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.

tidal silo
#

@lusty marsh Sorry to ping you, but I'm still very interested

lusty marsh
#

Oh yes

#

So the discussion was about result objects contra raising exceptions in the layer of api?

tidal silo
#

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.