4 ms·

It's still a net win. I program very fast-and-loose in Haskell. Sloppiness shows up a lot more visibly in the source code. If I write: (200, user) <- ge

by mrkeen 3y ago

It's still a net win. I program very fast-and-loose in Haskell. Sloppiness shows up a lot more visibly in the source code. If I write: (200, user) <- getUser userId I can see the tech debt right there on the page. I'll probably even get warnings. Even with with other variations like: getUser userId >>= \case (200, user) -> ... (404, _) -> ... _ -> error "TODO/FIXME This kind of thing tends to disappear in my Java day job: User user = getUser(userId); What's wrong with the above? Maybe nothing, maybe everything. I don't know! I need to start ctrl-clicking into definitions to try to hunt down the failure modes.

PaulHoule 3y ago
Note catching exceptions too close to where they are thrown is as much of a risk as catching them too far away. I have dealt with so much Scala code that is just too clever. Like the kind that tries to parallelize a trivial task but has race conditions anyway and doesn't use all the CPUs. You can spend two days trying to fix it or you can finish the job in 20 minutes with the ExecutorService.
- mrkeen 3y ago
  > Note catching exceptions too close to where they are thrown is as much of a risk as catching them too far away. Yes, another another reason to avoid them.
  - PaulHoule 3y ago
    And to avoid having any code ever fail. It was a formative experience to me to type in the source of a terminal emulator in C for CP/M that I ported to Microware’s OS-9 out of a 1984 Byte magazine that tried to do things the Either way without language support and noted about 4/5 of the code was error handling interspersed with the happy path. Either is not much better than errno in the end.