On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> 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" > > But expecting developers to do this at EVERY CALL is really impossible. > 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) 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.
