3 ms·

> The longer the exception handling blocks in a file, the more likely the file is to contain bugs. It is difficult to design a sophisticated error handling sys

> The longer the exception handling blocks in a file, the more likely the file is to contain bugs. It is difficult to design a sophisticated error handling system. For various reasons. For example it is rarely talked about -- everybody focuses on how to get stuff working and errors aren't really hot topic people find interesting. I think, given the above, you have most chance of success with really simple error handling systems. The simplest is to only handle things you can really handle at the current frame and let everything else filter to the top and interrupt entire process. It is not perfect but it has the virtue of being simple and easy to make foolproof. > The Ignoring Interrupted Exception and Log and Throw patterns corelated with post-release defects in one of the projects they studied, but not all. Interrupted exception does not happen in real usage in a lot of applications, especially backends, where the environment is very well controlled. Log and throw can be a legitimate pattern. It makes sense when the exception travels outside some kind of boundary like module/library boundary. A REST API is an example of boundary and it is normal to log the error but still throw it (to the client). It also may possibly make sense to log additional information available in local scope and throw the error up the stack. It doesn't always make sense to convert the type of the exception to be able to add more information to it.

gwbas1c 5y ago
> Log and throw can be a legitimate pattern. It makes sense when the exception travels outside some kind of boundary like module/library boundary. A REST API is an example of boundary and it is normal to log the error but still throw it (to the client). It also may possibly make sense to log additional information available in local scope and throw the error up the stack. It doesn't always make sense to convert the type of the exception to be able to add more information to it. Of course it's going to correlate with a bug. The whole point of log and throw is to make bugs easier to find!
TeMPOraL 5y ago
> It also may possibly make sense to log additional information available in local scope and throw the error up the stack. Like, time. This is why I often do "log and throw" or "log unexpected value and return it", depending on whether the code is exception-oriented or uses sum types instead. It's because time is an important piece of information to encode in an error log. When your error is caused by an external resource (e.g. RPC failure), you want to log it immediately to later be able to correlate it with external resource's logs or some other monitoring. If you don't the error may take some time to reach its final logging place - or, it may never reach it at all, if the application crashes in the meantime.
cies 5y ago
>The simplest is to only handle things you can really handle at the current frame and let everything else filter to the top and interrupt entire process. I find this approach creates exactly what you try to avoid: error handling complexity. The problem is with the Exceptions I believe. They mess with normal program flow. They create code that's hard to reason about, that's less explicit. Sometimes Exceptions can clean up some code, but usually it just sweeps dirt under the carpet to blow up in your face later. I rather use sum types and actual return statements (or implicit returns when all code is expressions) than Exceptions.

gwbas1c 5y ago

> Log and throw can be a legitimate pattern. It makes sense when the exception travels outside some kind of boundary like module/library boundary. A REST API is an example of boundary and it is normal to log the error but still throw it (to the client). It also may possibly make sense to log additional information available in local scope and throw the error up the stack. It doesn't always make sense to convert the type of the exception to be able to add more information to it. Of course it's going to correlate with a bug. The whole point of log and throw is to make bugs easier to find!

TeMPOraL 5y ago

> It also may possibly make sense to log additional information available in local scope and throw the error up the stack. Like, time. This is why I often do "log and throw" or "log unexpected value and return it", depending on whether the code is exception-oriented or uses sum types instead. It's because time is an important piece of information to encode in an error log. When your error is caused by an external resource (e.g. RPC failure), you want to log it immediately to later be able to correlate it with external resource's logs or some other monitoring. If you don't the error may take some time to reach its final logging place - or, it may never reach it at all, if the application crashes in the meantime.

cies 5y ago

>The simplest is to only handle things you can really handle at the current frame and let everything else filter to the top and interrupt entire process. I find this approach creates exactly what you try to avoid: error handling complexity. The problem is with the Exceptions I believe. They mess with normal program flow. They create code that's hard to reason about, that's less explicit. Sometimes Exceptions can clean up some code, but usually it just sweeps dirt under the carpet to blow up in your face later. I rather use sum types and actual return statements (or implicit returns when all code is expressions) than Exceptions.