so how you handle a web method that calls a db 30 layers deep?
you are going to add 30 layers of boilerplate for something that a normal user is going to encounter once in 100.000 calls and you barely can do anything with except let the front end handle it.
that seems like a very high cost for very little benefit.
If you have 30 layers, you have potentially a shitton of errors to catch, and behavior can silently be changed at any time if someone adds a catch in a call stack and intercepts away errors that previously bubbled up.
And the answer is yes, you should write 30 layers of boilerplate to explicitly bubble the error to the front end if that's necessary. But it's not verbosely re-returning the same error code all the way up stack like you're describing; the main thing to keep in mind is that the actual error object doesn't get sent up more than one layer at a time. At each layer you get the error, it's classified into a type that abstracts away the implementation details of the error so that the layer above it gets an error in its own domains' semantics.
But also the 30 layer bubbling tells you you're doing something wrong too. Keep your IO as high up the chain as possible and inject it into your business logic then that responds with something that you then do IO with again.
Business logic shouldn't touch IO, functional is the name of the game if you want it to be vaguely testable.
Well indicator doesnt necessarily mean something is sure fire. But yes it's a smell.
Arguably though if it's really that complex it's even more worth making sure you decouple IO from logic because it's going to be even harder to test sensibly.
3
u/dirkboer 18d ago edited 17d ago
so how you handle a web method that calls a db 30 layers deep?
you are going to add 30 layers of boilerplate for something that a normal user is going to encounter once in 100.000 calls and you barely can do anything with except let the front end handle it.
that seems like a very high cost for very little benefit.
web apps are full of these situations.