4 ms·

Isn't swallowing (and passing) exceptions pretty much what they are for? Should you instead handle every error close to their source, exceptions would be an ov

Isn't swallowing (and passing) exceptions pretty much what they are for? Should you instead handle every error close to their source, exceptions would be an overly verbose way of doing it. But maybe it's just my specific kind of programming prejudice shining through here.

the_af 6y ago
> Isn't swallowing (and passing) exceptions pretty much what they are for? No. You either pass them up or handle them. Silently swallowing them is a recipe for disaster, because nobody gets any info about what went wrong. In very limited cases -- e.g. "I don't care about this harmless error" -- it's correct to swallow them up, but Java devs tend to overuse it and disaster ensues. > Should you instead handle every error close to their source [...] You shouldn't. Handle those errors that it makes sense to handle, pass them up otherwise. Just don't swallow them.
knorker 6y ago
> Should you instead handle every error close to their source I find that this is very rarely the case. Micro-operations failing means that a MUCH higher level operation has failed. If there's an error writing to the output file descriptor from deep within the decompression library, do you know what failed? The HTTP request. What can the decompression library, the IDS inspector, the logging system, the tracing system, or anything else do? They can just pass along the error. Hence so much "if err != nil { return err}" in Go. The vast VAST majority of errors are not handled, they are reported. Verbose? benchmark b("blah"); write(http_compress(logsize(backend_decompress(out_fd, in_fd))) It's extremely rare that something can recover from an error. And the things that can be recovered from are not exceptions in C++ (though they seem to be in Java, brrr).