On Sunday, February 19, 2012 14:26:55 H. S. Teoh wrote: > 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.
I don't think that that's quite what he means. If you're using error codes in a function, you have to check them on practically every call to another function. This makes a mess of your code. If you use exceptions, on the other hand, you don't have any of those checks in your code. Rather, you wrap the code in a try-catch block, and put your error-handling code in one place within the function. _That_ is centralizing it. In some cases, that means a try-catch block at a higher level without any in sub functions, because it makes the most sense for a function higher up to handle the exceptions there (e.g. if you're going to want to pop up a dialag to ask the user to give a different file, you want that higher up, not in std.file), and in some cases, you want the try-catch block to be much closer to where the throw occurred (sometimes even in the same function). Now, maybe Andrei meant centralizing the error handling even more than that, but it makes so little sense to have _one_ place in your program handling all of the exceptions that I have a very hard time believing that that's what he really meant. - Jonathan M Davis
