4 ms·
>As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and r
by vitalyd 11y ago
>As an example, imagine you're building an application that you know uses sockets. And it's in the requirements that your application must be able recover and re-attempt set of operations. So you look into what kinds of network and socket exceptions exist in your platform, framework, and libraries. From there you decide which ones you should trap and attempt to retry.
You need to decide where you're going to handle them, and this depends on how much context is required to handle them appropriately. Sometimes this may require doing it right at the point where the method is invoked that triggers the exception. Even if you decide to not handle the exception, you may still want to know the exceptions so you can rollback/adjust state/invariants before letting the exception continue unwinding.
- wvenable 11y agoBut where you decide to handle an exception is independent of what methods trigger what exceptions. The decision as to where to put error handling code is based on the program structure and requirements. If my requirement is to rollback the current operation and retry, the error handling goes where that operation starts. I consider adjusting state based on the exception type poor design. That's very tight coupling. But even so, where you put that code is still independent of where exceptions are thrown. If your data state adjustment requires an exception type, check for that where that state change is appropriate. But what methods trigger what exceptions is still irrelevant.