On Wednesday, April 03, 2013 16:23:31 Lars T. Kyllingstad wrote: > On Wednesday, 3 April 2013 at 14:11:09 UTC, Steven Schveighoffer > > wrote: > > The problem I have with this whole scheme of one class per > > error type is, you inevitably cannot cover everyone's use case, > > so they end up having to catch a base class and then doing the > > work to figure out what it is manually. > > Precisely. And then, a switch over an enum is both way more > efficient and more readable than a bunch of ifs and casts.
Except that the enum solution doesn't work at all when a 3rd party needs to add an error type to the mix, so they'll subclass it, and in the general case, you're forced to deal with the base class regardless. In general, I think that using error codes in exception types like you're basically suggesting is not properly taking advantage of the language's built- in exception features. catch is _designed_ for differentiating between errors, and using error codes in exceptions circumvents that. I think that the only case where it's cleaner to have the code is when you want to handle two exceptions of differing types with the same handler but don't want to handle all exceptions with their common base type in the same way. Other than that, I think that it's much better to let catch do its job - especially when people _do_ need to handle each exception type differently. - Jonathan M Davis
