4 ms·
> Lots of us have since observed that this approach to failure leads to errors because programmers ignore failures, allowing them to be handled by a catch-all a
by flowerlad 5y ago
> Lots of us have since observed that this approach to failure leads to errors because programmers ignore failures, allowing them to be handled by a catch-all at the top of the stack, which typically just dumps a stacktrace and calls it a day.
That's not typical Java code. You could do that in quick & dirty code, but I haven't seen such code in production code.
- lolinder 5y agoThen you're lucky. I have, both on the developer side and on the user-getting-a-stacktrace side. It's not pretty from either end.
- catlifeonmars 5y agoAnecdata: but I see this pattern all the time in production code. It’s not limited to Java: I’ve seen it in TS/JS, Python, and C++. I haven’t (yet) seen it our Go codebases.
- blindluke 5y ago> That's not typical Java code. You could do that in quick & dirty code, but I haven't seen such code in production code. It sounds to me like you're an extremely lucky person. I've seen too much of that sort of thing in production code, including a catch-all for Throwable at the top that didn't even dump a stacktrace.
- loopz 5y agoTypically this is passed to production and not seen by devs. Ie. there's no point to handle NullPointer explicitly (programmer error).