Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ MagicMoonlight 7 hours ago

Notice how this slop doesn't happen in real languages like C++ or Java. It's only the slop languages.

You don't need a "is it a number" package in java, because the function cannot be passed a string, because it actually has a type system. All this slop has come about because meme developers refuse to accept the truth - programming languages have proper syntax for a reason.

▲PaulHoule 5 hours ago | parent [-]

Partially true.

A lot of times you have something in Java which could be

   ReturnValue someMethod(Parameter p) {
      …
      var x = anotherMethodThatMightThrowAnException(q);
      …
   }
and I’m going to argue that often that’s good enough but a lot of people think it isn’t so they might put 20 lines of code above that line to head off that exception or they might put it in a try-catch block [1] to respond to it or wrap it. Those unhappy paths bloat your code the same way as the guards in the blog post, make it unclear how the happy path works at a glance (place for bugs to hide in the happy path) and obviously create opportunities for bugs in the unhappy path.

I’ll argue that (1) error handling is a function of the application as a whole or of a “unit of work” (e.g. database transaction) so unless you’re at the top level method of a unit of work you should “let it throw”, (2) try-finally is preferable to try-catch when it comes to cleaning up and tearing down, and (3) it is fair to wrap and rethrow exceptions if you want the unit of work manager to have more context to know what to do, or provide a better error message.

In theory, you could spend time writing and maintaining error preempting and handling code and get better error messages. However that code isn’t always correct. One funny thing about AI agent programming for me is that if I ask Junie to code me some tests it works harder at testing unhappy paths than I would.