Towards a better conceptual model of exceptions (Was: Re: The Right Approach to Exceptions)
Jonathan M Davis
jmdavisProg at gmx.com
Tue Feb 21 11:40:30 PST 2012
On Tuesday, February 21, 2012 00:15:48 H. S. Teoh wrote:
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
More information about the Digitalmars-d