Program logic bugs vs input/environmental errors (checked exceptions)

[H. S. Teoh via Digitalmars-d]

On Tue, Oct 07, 2014 at 04:14:57PM -0700, Jeremy Powers via Digitalmars-d wrote:
> On Tue, Oct 7, 2014 at 3:44 PM, H. S. Teoh via Digitalmars-d <
> digitalmars-d at puremagic.com> wrote:
[...]
> > But what if we allow catch blocks to be "templated"?
> >
> > We could then introduce signature constraints to catch blocks, that
> > determine generically whether some unknown incoming exception type
> > matches certain required characteristics (in the same way range
> > algorithms accept any type that satisfy the range API), and then the
> > catch block would be able to operate on that exception without actually
> > being tied down to a concrete exception type.
> >
> > For classification purposes, of course, we still require exceptions to
> > subclass Exception. But a catch block could potentially accept multiple
> > unrelated Exception subclasses via ducktyping, e.g.:
> >
> >         class Exception : Throwable { ... }
> >         class JSONParseError : Exception {
> >                 string filename;
> >                 size_t line;
> >                 JSONParser parser;
> >         }
> >         // N.B. there is no common base class between ScriptRunnerError
> >         // and JSONParseError.
> >         class ScriptRunnerError : Exception {
> >                 string filename;
> >                 size_t line;
> >                 Interpreter interp;
> >         }
> >         ...
> >         void main() {
> >                 try {
> >                         doStuff();
> >                 } catch (E : Exception)(E e)
> >                         if (is(typeof(e.filename) : string) &&
> >                             is(typeof(e.line) : size_t))
> >                 {
> >                         // can use .filename and .line here.
> >                 }
> >         }
[...]
> But not sure I see the usefulness of how this idea came out.
> 
> In your example, where you just check the types of members of the
> exception, this is equivalent to the 'unknown variable members' that
> was railed against earlier.  It says nothing about the actual
> type/kind of exception, only about what additional baggage information
> the exception carries.  Maybe somewhere in the bowels of doStuff() an
> exception was thrown where 'filename' refers to a dump file created,
> and 'line' is the product line that barfed...

Hmm, you're right. This is not much different from Andrei's idea to use
Variant[string]. The interpretation of filename/line must be somehow
agreed upon, either by convention, or by a common base class. So this
doesn't get us beyond exception class hierarchies. :-(


T

-- 
Don't throw out the baby with the bathwater. Use your hands...