4 ms·

It's a waste of time to check most errors. Usually they don't have enough context to diagnose a problem, and they can generate a lot of unnecessary noise. Catch

It's a waste of time to check most errors. Usually they don't have enough context to diagnose a problem, and they can generate a lot of unnecessary noise. Catching exceptions is one thing, but just saying 'error!' or having specific logic for each and every potential failure just leads to spaghetti code that doesn't really help your overall system. Instead, you should measure the overall "golden signals" of application/service/system health, and if you find a problem with those, you can start tracing calls, which will show you the erroring system calls. Cross-referenced with other metrics, you find the root cause. This is for when your application is part of a larger system, anyway. If you're writing a monolithic application where the entire system is your application and it can never go down, then checking and handling every error is more useful, but then your monolith starts to internally resemble a complex system and you're back to too much noise.

asveikau 7y ago
Ok, so this is pretty much counter to my experience. I've spent a significant chunk of my career just diagnosing errors based on error codes. It does work. When the kernel tells you some data is not found, permission is denied, or the filesystem is corrupt, or I/O failed, it really isn't kidding, it gives you specific advice and you should pay attention. You can also do things like look in kernel source to see when that error occurs, and depending on the error get really specific ideas about the problem. Keep in mind not every job will have you with total control of a machine as in a server use case. In many domains deploying code to someone else's device you won't know that you're running somewhere short of disk space, or whatever, until you see it in the error code. Further, I suspect you are working in higher level languages where somebody has already wrapped the error codes in exceptions, and already logs unhandled exceptions to stderr. So what I would call very basic "error handling" is already done for you. When talking about C, if this more manual work is not done, ignoring error codes and continuing to keep on chugging is just stupid in a lot of cases, will cause you to silently lose customer data if you don't stop yourself on the error, etc., which is bad times.

asveikau 7y ago

Ok, so this is pretty much counter to my experience. I've spent a significant chunk of my career just diagnosing errors based on error codes. It does work. When the kernel tells you some data is not found, permission is denied, or the filesystem is corrupt, or I/O failed, it really isn't kidding, it gives you specific advice and you should pay attention. You can also do things like look in kernel source to see when that error occurs, and depending on the error get really specific ideas about the problem. Keep in mind not every job will have you with total control of a machine as in a server use case. In many domains deploying code to someone else's device you won't know that you're running somewhere short of disk space, or whatever, until you see it in the error code. Further, I suspect you are working in higher level languages where somebody has already wrapped the error codes in exceptions, and already logs unhandled exceptions to stderr. So what I would call very basic "error handling" is already done for you. When talking about C, if this more manual work is not done, ignoring error codes and continuing to keep on chugging is just stupid in a lot of cases, will cause you to silently lose customer data if you don't stop yourself on the error, etc., which is bad times.