On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> On 10/6/14, 7:01 AM, H. S. Teoh via Digitalmars-d wrote: > >> On Mon, Oct 06, 2014 at 06:46:31AM -0700, Andrei Alexandrescu via >> Digitalmars-d wrote: >> >>> On 10/5/14, 11:39 PM, Dmitry Olshansky wrote: >>> >>>> >>>> It's obvious to me that one hierarchy is way to limiting for >>>> exceptions, simply because there could be many ways to categorize the >>>> same set of error conditions. >>>> >>> >>> Well put. -- Andrei >>> >> >> What's the alternative, though? I can't think of any solution that >> (1) isn't far more complicated than the current state of things and >> (2) is easier to use. >> > > I'm thinking a simple key-value store Variant[string] would accommodate > any state needed for differentiating among exception kinds whenever that's > necessary. > > And 'kinds' is a synonym for 'types' - You can have different kinds of problems, so you raise them with different kinds of exceptions. s/kind/type/g and the question is: why not leverage the type system? For a consumer-of-something-that-throws, having different types of exceptions for different things with different data makes sense. You have to switch on something to determine what data you can get from the exception anyway. > It's commonly accepted that the usability scope of OOP has gotten > significantly narrower since its heydays. However, surprisingly, the larger > community hasn't gotten to the point to scrutinize object-oriented error > handling, which as far as I can tell has never delivered. > Maybe, but what fits better? Errors/Exceptions have an inherent hierarchy, which maps well to a hierarchy of types. When catching an Exception, you want to guarantee you only catch the kinds (types) of things you are looking for, and nothing else.