<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer 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">The largest issue I see with this whole scheme is that exceptions can be turned into errors, but not the reverse. Once an error is thrown, it's pretty much game over. So defensive coding would suggest when you don't know the answer, throw an exception, and something higher up would say "Oh, that is really a program error, rethrowing"<br>
<br>
But expecting developers to do this at EVERY CALL is really impossible.<br></blockquote><div><br></div><div>And this is an argument for checked exceptions - being able to explicitly state 'these are known fatal cases for this component, you should deal with them appropriately' when defining a method.  Cuts down the catch/check to just the common cases, and makes such cases explicit to the caller.  Anything not a checked exception falls into the 'error, abort!' path.  (Memory corruption etc. being abort scenarios)</div><div><br></div><div>If I really needed to write a robust program in D right now, I would (attempt) to wrap every call in a try/catch, and check if the thrown exception was of a handleable type.  But knowing which types for which methods would lead me to basically hacking up some documentation-enforced checked exceptions, and being entirely unmaintainable.</div><div><br></div><div><br></div></div></div></div>