<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 6, 2014 at 6:19 PM, Andrei Alexandrescu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/6/14, 4:46 PM, Jeremy Powers via Digitalmars-d wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mon, Oct 6, 2014 at 7:50 AM, Andrei Alexandrescu via Digitalmars-d<br></span><span class="">
I'm thinking a simple key-value store Variant[string] would<br>
accommodate any state needed for differentiating among exception<br>
kinds whenever that's necessary.<br>
<br>
<br></span><span class="">
And 'kinds' is a synonym for 'types' - You can have different kinds of<br>
problems, so you raise them with different kinds of exceptions.<br>
<br>
s/kind/type/g and the question is: why not leverage the type system?<br>
</span></blockquote>
<br>
I've used "kinds" intentionally there. My basic thesis here is I haven't seen any systematic and successful use of exception hierarchies in 20 years. In rare scattered cases I've seen a couple of multiple "catch"es, and even those could have been helped by the use of a more flat handling. You'd think in 20 years some good systematic use of the feature would come forward. It's probably time to put exception hierarchies in the "emperor's clothes" bin.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For a consumer-of-something-that-<u></u>throws, having different types of<br>
exceptions for different things with different data makes sense. You<br>
have to switch on something to determine what data you can get from the<br>
exception anyway.<br>
</blockquote>
<br></span>
Oh yah I know the theory. It's beautiful.<br>
<br></blockquote><div><br></div><div>I'm not talking theory (exclusively). From a practical standpoint, if I ever need information from an exception I need to know what information I can get. If different exceptions have different information, how do I tell what I can get? Types fits this as well as/better than anything I can think of.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
It's commonly accepted that the usability scope of OOP has gotten<br>
significantly narrower since its heydays. However, surprisingly, the<br>
larger community hasn't gotten to the point to scrutinize<br>
object-oriented error handling, which as far as I can tell has never<br>
delivered.<br>
<br>
<br></span><span class="">
Maybe, but what fits better? Errors/Exceptions have an inherent<br>
hierarchy, which maps well to a hierarchy of types. When catching an<br>
Exception, you want to guarantee you only catch the kinds (types) of<br>
things you are looking for, and nothing else.<br>
</span></blockquote>
<br>
Yah, it's just that most/virtually all of the time I'm looking for all. And nothing else :o).<br><br></blockquote><div><br></div><div>Most/virtually all of the time I am looking only for the kind of exceptions I expect and can handle. If I catch an exception that I was not expecting, this is a program bug (and may result in undefined behavior, memory corruption, etc). Catching all is almost _never_ what I want.</div><div><br></div><div><br></div><div>I have not found a whole lot of use for deep exception hierarchies, but some organization of types/kinds of exceptions is needed. At the very least you need to know if it is the kind of exception you know how to handle - and without a hierarchy, you need to know every single specific kind of exception anything you call throws. Which is not tenable.<br></div><div><br></div><div> </div></div><br></div></div>