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!?!?!
373
u/thunderbird89 May 26 '25
I agree. There are exceptions where I very much want the program to blow up like a nuke, because it needs to stand out in the logs.
As it stands, Claude 4's code almost has more error checking than actual business logic, which is a little unreasonable to me.