The Right Approach to Exceptions

[H. S. Teoh]

On Sun, Feb 19, 2012 at 08:35:08AM -0600, Andrei Alexandrescu wrote:
> On 2/19/12 6:35 AM, deadalnix wrote:
> >Le 19/02/2012 09:02, Andrei Alexandrescu a écrit :
> >>>>I'm thinking an error is transient if retrying the operation with the
> >>>>same exact data may succeed. That's a definition that's simple,
> >>>>useful, and easy to operate with.
> >>>[...]
> >>>
> >>>But if that's the case, what's the use of an exception at all?
> >>
> >>Centralization.
> >>
> >>Andrei
> >>
> >
> >Please stop answering like that. From the begining of this topic
> >Jonathan M Davis, H. S. Teah (and myself ?) raised very valid points.
> >What do you expect from that discussion if yourself you do not put any
> >arguement on the table ?
> 
> The answer is meaningful. The purpose of exceptions is allowing for
> centralized error handling, and a capabilities-based system makes that
> simple (e.g. you get to make decisions about recoverability in one
> place, regardless of which part of the exception hierarchy the
> exception originated.
[...]

And how exactly do you propose centralized error handling to work in a
GUI application, one of the many dialogs of which asks the user for a
filename, and retries if the file doesn't exist? If the low-level
filesystem code throws an exception, which could be anything from file
not found to disk error to out of memory, then how exactly does your
"centralized error handler" determine what course of action to take? How
does it know which dialog to retry?

You're trying to have a centralized error handler that handles *all*
exceptions regardless of where they come from and what triggered them,
and independently of what operation might need to be retried if an
exception does happen? I can't see how such a system could possibly be
realized in a concrete way. This sounds like premature generalization to
me.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??