Program logic bugs vs input/environmental errors

[Jeremy Powers via Digitalmars-d]

On Mon, Sep 29, 2014 at 8:13 AM, Steven Schveighoffer via Digitalmars-d <
digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140929/a67801ce/attachment.html>