[femngi]

Yeah, I'm just going to go ahead and disagree anyway. Not only are they a poor structure for flow control they are an inefficient and slow one too, as Andrei mentions in his 2012 talk on expected<T>, a talk which also nicely illustrates the shortcomings of using them for their intended purpose as error handling.

In fact exceptions as implemented in C++ has to be one of my last favourite things about the language. They are an all or nothing proposition and yet were put in half heated and unchecked. Many years later the result I see is some or most programs have a catch(...) at some high level. Something went wrong, who knows what, can't even set the debugger to break at exceptions because they're being thrown everywhere all the time for flow control.

[peterfirefly]

C++ exceptions came from ML.

The original purpose in ML was definitely control flow. Or rather, controllable heuristic search in the context of a proof assistant. A heuristic could "give up" by raising an exception and a meta heuristic would then try something else or give up.

They worked well because memory handling is clean and automatic in ML and because proof assistants mainly work in their own little world with little to no I/O (apart from logging to a file/stdout/stderr).

[simoncion]

> ...can't even set the debugger to break at exceptions because they're being thrown everywhere all the time for flow control.

Any C++ debugger worth using will allow you to break on certain exceptions and ignore others. Even gdb permits this: http://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.htm... Any decently designed C++ program will have a sane set of exception classes that will be easy to filter when debugging.

[toolslive]

The heuristic is that if the case is more frequent than something like 1/1000 then you don't use exceptions in these languages (C++, Java, ...). As they are a lot cheaper in languages like ML, people there tend to use them more for early exits out of things like folds.

A simple example:

  let prod = List.fold_left (fun acc a -> acc * a) 1.0 xs

should not fold over the whole list if a factor is 0.0 so they tend to use exceptions for that (or delimited continuations)

[kyllo]

Java doesn't really give you a choice though, because so many of the standard library classes have exceptions baked in. Any code you write related to file I/O for example will have to have either a "throws" or a "try/catch" on it, or else it won't even compile.

[judk]

Checked exceptions are much closer to "error codes" than unchecked exceptions. Checked exceptions just loosen the constraint a bit and let you defer handling to anywhere the caller's remaining function scope (or explicitly continue the throw)