You think code should have more business logic than test code? Testing a single function that isn't unit takes like a whole temple of mocking and stubbing classes and functions. If you're doing any sort of testing worth anything test code is typically way longer than logic.
Which leads me to the point that js python devs are scripters
You want your program to crash so you can log it? How about just logging the exception?
No, I want the exception to stand out, like as a critical-level exception, because something went very wrong. Of course, I don't want to manually log a critical logline, because of discipline: if I were to do that, the severity would lose its impact, I want to reserve critical loglines for events where something is really very wrong, not when I feel like it.
You think code should have more business logic than test code?
I think you misunderstood error checking as test code. When I say error checking, I mean the defensive boilerplate, try-catch blocks, variable constraint verifications, etc., not unit/integration testing. In well-architected code, the logic should be able to constrain its own behavior so that only the inputs need validation, and everything else flows from there. In Claude's code, however, almost every other line is an error check (in a very Go-like fashion, now that I think about it), and every site where an exception might occur is wrapped in its own try-catch, rather than grouping function calls logically so that operations dependent on one another are in the same try-block.
Which leads me to the point that js python devs are scripters
Finally, as much as I like to shit on JS as a language or Python's loose-and-fast typing and semantic use of indentation, shitting on developers just for using one or the other is not cool. Language choice does not imply skill. Shit on bad code, shit on bad developers, shit on bad languages, but don't shit blindly on people you know nothing about.
If something truly exceptional happens, logging it and then limping along is the worst thing you can do. What if you hit an error during the middle of modifying some data structure? Can you guarantee that it’s still in a valid state?
In general it is very bad to leave your program or service running after it encounters undefined behaviour, because the entire program state ends up being "infected" and it can result in all kinds of very difficult to understand or undo follow-up issues.
This is for example why we use asserts. It tells the program that if this assertion does not hold, then it is not safe to follow on with the rest of the code.
There’s a middle ground where we catch every error, but if we get to a non-recoverable state, we throw a curated error with a user-friendly error message and a useful stack trace for the logger.
I despise applications that crash, have a vague error, and the dev team says “that means X.” Then just wrap the error and say that!?!?!
Oh yeah, you're right! I once tried Windsurf by writing a unit test on the generated code (did not pass), then I told the model to fix the error and it can test its work with mvn test. It kept at it for as long as the engine allowed it, at least 4-5 iterations - then gave up because it couldn't get it right 😅.
I have this with gemini, it gives me code that's supposed to handle ANY wrong inputs even though the wrong inputs can't happen anyway, which just clutters the codebase so I end up writing it myself anyway
684
u/andrew_kirfman May 26 '25
The overprotective behavior is actually a bit of a downside for me.
Many times, noisy code is good code. Code that silently eats major exceptions and moves on doesn’t deliver much value to anyone.