3 ms·

By saying "Exceptions exist so that you can treat error handling as a separate concern" you are again putting the conclusion first. Maybe exceptions were inven

By saying "Exceptions exist so that you can treat error handling as a separate concern" you are again putting the conclusion first. Maybe exceptions were invented for handling errors, but now that we have them, what's a good reason not to use them for other purposes?

h2s 14y ago
Because using exceptions as control flow introduces a very awkward and strange type of coupling between components: dependence by one component on the presence of another known component higher up in the call stack. Dependencies between components should ideally be as explicit and as few as possible. Dependency injection is one good way of achieving this, but even global variables or singletons are more clearly self-documenting than exceptions. A piece of code that returns a value or makes a call to some functionality in another piece of code is easy to understand. If instead, that code throws an exception, then it sends the reader on a voyage of discovery throughout the codebase to investigate all the places that catch this type of exception, and which of those pieces of code can ever potentially be higher in the call stack than the piece that throws it. The only reason we even put up with such complexity in the case of handling errors is that it is the one problem that is ubiquitous to every piece of software ever written and therefore merits its own first-class language support.
- andyjpb 14y ago
  Throwing exceptions across API and module boundaries is a separate discussion which has separate pros and cons. When you define an API in a language that has exceptions you should be careful to define the behaviour around how exceptions are used. This is similar to how, when you define an API in a language that has threads, you should be careful to define your reentrancy and thread-safety guarantees.
- perlgeek 14y ago
  So you wouldn't object to it if catching and throwing happens in the same component (however you define component)?
  - h2s 14y ago
    To truly minimise the potential for confusion with this approach, you'd need to be throwing and catching within the same method. And if you're doing that, you might as well just come out of the closet and use goto.
Tloewald 14y ago
http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T... http://www.ckwop.me.uk/Why-Exceptions-Suck.html http://www.ckwop.me.uk/Why-Exceptions-Suck.html Not saying that this is the last word on exceptions, but these are the arguments.

h2s 14y ago

Because using exceptions as control flow introduces a very awkward and strange type of coupling between components: dependence by one component on the presence of another known component higher up in the call stack. Dependencies between components should ideally be as explicit and as few as possible. Dependency injection is one good way of achieving this, but even global variables or singletons are more clearly self-documenting than exceptions. A piece of code that returns a value or makes a call to some functionality in another piece of code is easy to understand. If instead, that code throws an exception, then it sends the reader on a voyage of discovery throughout the codebase to investigate all the places that catch this type of exception, and which of those pieces of code can ever potentially be higher in the call stack than the piece that throws it. The only reason we even put up with such complexity in the case of handling errors is that it is the one problem that is ubiquitous to every piece of software ever written and therefore merits its own first-class language support.

andyjpb 14y ago
Throwing exceptions across API and module boundaries is a separate discussion which has separate pros and cons. When you define an API in a language that has exceptions you should be careful to define the behaviour around how exceptions are used. This is similar to how, when you define an API in a language that has threads, you should be careful to define your reentrancy and thread-safety guarantees.
perlgeek 14y ago
So you wouldn't object to it if catching and throwing happens in the same component (however you define component)?
- h2s 14y ago
  To truly minimise the potential for confusion with this approach, you'd need to be throwing and catching within the same method. And if you're doing that, you might as well just come out of the closet and use goto.

Tloewald 14y ago

http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html http://www.u.arizona.edu/~rubinson/copyright_violations/Go_T... http://www.ckwop.me.uk/Why-Exceptions-Suck.html http://www.ckwop.me.uk/Why-Exceptions-Suck.html Not saying that this is the last word on exceptions, but these are the arguments.