3
neeno
4y

Coworker: let's use Result monads in the project so that we're forced to deal with exceptions
Me: okay, sounds great!
Me: *implements Result monads *everywhere**
Coworer: how about we don't use results anymore in half the project? It makes the code look ugly. Let's just use exceptions.
Me: ...

Really? Why in your mind is it okay to only force us to handle a few exceptions and others we can just say fuck it and let them wander around?

Oh you want to use try-catch for these other exceptions.

So now we're back at square one, which is trying to remember/figure out which exceptions any method can throw (since the compiler doesn't do shit, not even warnings), but now we also have inconsistent and much less readable code. Isn't it great?

(╯°□°)╯︵ ┻━┻

I also can't do much about it, because I'm just a fucking intern and I do not want to cause trouble, so I just try to say that I disagree with it in the most polite of ways and that's that.

Comments
  • 0
    I think the rant came out with a much angrier tone than I actually am, I'm not pissed, just a bit bothered by it. Whatever, anger = fun around here doesn't it? I'll leave it like that just for the updoots.
  • 2
    I see absolutely zero reasons to not use result monads. Your co-worker needs some sense batted into their empty head
  • 1
    @100110111 Yup. "I don't wanna deal with it" isn't a good idea when it comes to error handling
  • 1
    I feel you.
    Can't say I haven't been there.

    I spent my time doing it anyways then had the PR rejected.
    Only to get later asked to do exception handling a week later 🤣
Add Comment