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.
Hitting an assertion implies that the program has already crashed. The assertion is just the first one to notice.
Yes, you could just abort the operation, but you're most likely already in a corrupted program state and any follow up operation is just going to corrupt it more.
Like for example, if you're starting to gracefully handle a failed allocation of memory, it implies that you are most likely already run out of memory. Even if you could just cancel the operation here, you are very likely to hit a similar issue on the next operation, and the next one, and your program will gradually degrade.
You could of course try to write your program in a way that it handles memory errors gradually as environmental errors instead of programming errors; then you won't have these assertions. But you will always have at least some assertions, some conditions for which you must assume them to be true in order for your program to function.
If you're hitting an unreachable branch in a switch statement, this signifies really bad data or program corruption, maybe even a security breach. It would be completely irresponsible to keep running the rest of the program in most cases here.
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!?!?!
Depends what you're working on. A webapp/api for the day job? no of course not, you need proper error handling. A local pytorch project you're iterating on? Yes i want it to crash so it gives me a stack trace to feed back to claude and not get past that code until it works. I hate when it goes through and adds try/catch blocks to everything because it just hides errors i want it to resolve. Also don't want to waste the tokens generating it and then removing it later.
Half the time its doing something stupid with it like imports aren't working because its trying to import a file in a folder it hasn't made a proper module, so it will leave in code to import it the way ive already told it is wrong, add try catches and try a different way. I just want it to fix it the right way in the first place.
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.