☆ Yσɠƚԋσʂ ☆@lemmy.ml to Programmer Humor@lemmy.mlEnglish · 12 days agoOOP theory vs practicelemmy.mlexternal-linkmessage-square49fedilinkarrow-up1191arrow-down12
arrow-up1189arrow-down1external-linkOOP theory vs practicelemmy.ml☆ Yσɠƚԋσʂ ☆@lemmy.ml to Programmer Humor@lemmy.mlEnglish · 12 days agomessage-square49fedilink
minus-squaresbv@sh.itjust.workslinkfedilinkEnglisharrow-up13·11 days ago I thought those were for only when shit is seriously wrong and execution can’t continue in the current state. That’s how it starts. Nice and simple. Everyone understands. Until some resource was in a bad state and you decide you want to recover from that situation, but you don’t want to refactor all your code. Suddenly, catching exceptions and rerunning seems like a good idea. With that normalized, you wonder what else you can recover from. Then you head down the rabbit hole of recovering from different things at different times with different types of exception. Then it turns into confusing flow control. The whole Result<ReturnValue,Error> thing from Rust is a nice alternative.
That’s how it starts. Nice and simple. Everyone understands.
Until
and you decide you want to recover from that situation, but you don’t want to refactor all your code.
Suddenly, catching exceptions and rerunning seems like a good idea. With that normalized, you wonder what else you can recover from.
Then you head down the rabbit hole of recovering from different things at different times with different types of exception.
Then it turns into confusing flow control.
The whole Result<ReturnValue,Error> thing from Rust is a nice alternative.