3 ms·
Exceptions are not a GOTO: - they cannot make you end up any place in the code, only up the stack. - going up in the stack, it leads to the destruction of any
by BiteCode_dev 5y ago
Exceptions are not a GOTO:
- they cannot make you end up any place in the code, only up the stack.
- going up in the stack, it leads to the destruction of any frame in the way.
- the exception object carries metadata about the origin and propagation.
- calling code can subscribe to the event and act on it. Handling is decoupled from raising.
- calling code can interrupt (in multiple spots) or stop the propagation.
- aranchelk 5y agoMany excellent points. I had never encountered the idea of exception=goto. My initial thoughts: 1) In the case of goto, behavior is determined in the invocation. Conversely, when throwing an exception, the behavior is determined by the surrounding try block, which very is often well outside the scope of that throw. In this sense they seem like polar opposites. 2) You can model exceptions as monads: create a wrapper type that can either hold a regular value or a failure. Then create a helper function that processes these wrapped values. When encountering a wrapped regular value, the helper unwraps it and runs the next computation; on encountering a failure the helper skips the next computation and passes on the failure. The computations take unwrapped regular values as input, but they return the wrapped type. Not only is this how exceptions are done in pure functional languages, to my mind it’s the most implementation-independent way to think about what they actually are. This description bears no resemblance to goto.