Towards a better conceptual model of exceptions (Was: Re: The Right Approach to Exceptions)

[Jonathan M Davis]

On Tuesday, February 21, 2012 00:15:48 H. S. Teoh wrote:
> TRANSITIVITY

I still contend that this useless, because you need to know what went wrong to 
know whether you actually want to retry anything. And just because the 
particular operation that threw could be retried again doesn't mean that the 
code that catches the exception can retry the function that _it_ called which 
resulted in an exception somewhere down the call stack. And often, you don't 
even know which function it was that was called within the try block. So, I 
don't see how transivity really matters. If you know what what wrong - which 
the type of the exception will tell you - then _that_ is what helps your code 
make a useful decision as to what to do, not a transivity property.

So, yes. A particular exception type is generally transitive or not, but you 
know that by the nature of the type and the problem that it represents. I 
don't see how focusing on transivity is useful.

> The try-catch mechanism is not adequate to implement all the recovery
> actions described above. As I've said before when discussing what I
> called the Lispian model, some of these recovery actions need to happen
> *in the context where the exception was thrown*. Once the stack unwinds,
> it may not be possible to recover anymore, because the execution context
> of the original code is gone.

> This is where the Lispian model really shines. To summarize:

try-catch and Exceptions are built into the language. Exceptions are part of 
not only the standard library but the runtime. They're not perfect, but they 
_work_. I really think that this whole thing is being way overthought and 
blown out of proportion.

Using another recovery mechanism in your programs (built on top of exceptions 
or otherwise) is fine, but I really don't see a need to seriously alter how 
error handling is done in the language as a whole. We're _way_ past the point 
where it makes sense to completely redesign how exceptions work. And I 
_really_ don't think that it's a good idea to change anything major about how 
error handling is done in the standard library without a lot of real world 
experience with whatever you want to replace it with. And we don't have that.

So, I see no problem with you experimenting, but I don't think that we should 
be drastically changing how the standard library functions with regards to 
exceptions. We would definitely gain something by cleaning up how they're 
organized, and maybe adding additional capabilites to improve their printing 
abilities like Andrei wants to do would be of some value, but we don't need a 
complete redesign, just some tweaks.

- Jonathan M Davis