On Sunday, February 19, 2012 02:06:38 Andrei Alexandrescu wrote: > On 2/19/12 1:12 AM, Jonathan M Davis wrote: > > On Sunday, February 19, 2012 00:43:58 Andrei Alexandrescu wrote: > >> On 2/18/12 8:00 PM, H. S. Teoh wrote: > >>>> From this and other posts I'd say we need to design the base > >>>> exception > >>>> > >>>> classes better, for example by defining an overridable property > >>>> isTransient that tells caller code whether retrying might help. > >>> > >>> Just because an exception is transient doesn't mean it makes sense to > >>> try again. For example, saveFileMenu() might read a filename from the > >>> user, then save the data to a file. If the user types an invalid > >>> filename, you will get an InvalidFilename exception. From an abstract > >>> point of view, an invalid filename is not a transient problem: retrying > >>> the invalid filename won't make the problem go away. But the application > >>> in this case *wants* to repeat the operation by asking the user for a > >>> *different* filename. > >>> > >>> On the other hand, if the same exception happens in an app that's trying > >>> to read a configuration file, then it *shouldn't* retry the operation. > >> > >> 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. > > > > A core problem with the idea is that whether or not it makes sense to try > > again depends on what the caller is doing. In general, I think that it's > > best to give the caller as much useful information is possible so that > > _it_ can decide the best way to handle the exception. > > That sounds like "I violently agree".
Then I'm confused. "As much information as possible" is way more than a transient property. If my code is going to retry or do something else or give up, it needs enough information to know what went wrong, not just whether the function which was called think it might work on a second try. Having an exception hierarchy provides some of that information simply with the types, and makes it easier to organize code based on what went wrong (e.g. separate catch blocks for each type of exception). And having that hierarchy also means that the derived types can have additional information beyond their type which could be useful but is specific to that problem and so wouldn't make sense on a general exception type. I really don't see what transient buys you in comparison to that. - Jonathan M Davis
