[gordonguthrie]

I think the disclaimer about Exceptions being a suitable form of GOTO is a big mistake.

When I started using Erlang I was amazed at how error handling and all that 'necessary' gumph just disappeared. In the Erlang world exceptions aren't handled up the call stack - when an Erlang process hits an error it just exits.

The Erlang control approach is that for each (restartable) worker process that does something there is a supervisor process whose only job is to catch 'I have died because...' messages from its children and restart sub-systems as appropriate.

It is just amazing what this approach does. There is no longer a 'fog of exception handling' necessary to keep the system running in the prescence of errors, there are clear and consistent reports of ALL errors - which means you can start squashing the bugs that cause them and iterate towards error-free programming.

[arithma]

I think the author meant "There are exceptions, in the real life meaning of the word", rather than the unwind-the-stack-when-a-bobo-happens programming construct.

[gordonguthrie]

> For the one case where people needed global control flow transfer (error handling) exceptions were developed. This was a progress from the extreme universality and abstraction of a goto-driven program to the concretion and specificity of pieces (such as procedures) solving specific problems.

'Throw' just means 'GOTO up somewhere' it is a posh goto...

[JoeAltmaier]

NOt quite - throw doesn't specify where to go, leaves it up to the caller. Very much more useful.

[gordonguthrie]

Yeah, but the problem with GOTO isn't at the GOTO end - that is usually very clear - in this case go here...

The real problem is at the arrival point 'where has the thread of execution come from, and what state is the programme in'.

Exceptions have the same arrival problem 'where in the code did this come from, and what was the state when it was thrown?'

[zwieback]

Time to bring up the COME FROM statement: http://en.wikipedia.org/wiki/COME_FROM