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

[Jeremy Powers via Digitalmars-d]

On Tue, Oct 7, 2014 at 3:44 PM, H. S. Teoh via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

[snip a bunch of stuff where we totally agree with each other]


> Having said all that, though, an idea occurred to me. While it's
> certainly true that the catch block must catch a *specific* type of
> exception -- otherwise there's no meaningful way to act upon it -- I
> haven't seen any strong evidence that a *class hierarchy* is required.
> Having been a skeptic of the OO craze where everything and everyone is
> shoehorned into the OO mode of thinking, misfits be damned, and having
> experienced the true power of metaprogramming in D, I wonder if a more
> flexible approach would be to use a templated, duck-typing kind of
> approach to exceptions instead of a class hierarchy.
>
> Basically, this boils down to the thought that the relationship between
> the throw statement and the corresponding catch block is in many ways
> analogous to a function call: the thrower (caller) has some pieces of
> info to pass on to the catcher (callee), and the type system allows the
> two to communicate and agree on the interpretation of this info. The
> current exception class hierarchy approach is akin to requiring all
> catch blocks to have signature function(Exception e).


This sounds a bit like reinventing checked exceptions.  At least, it shows
the same problem of having exceptions be part of the contract of methods.



> 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.
>                 }
>         }
>
> This way, things don't have to be in a hierarchy, yet the catch block
> can meaningfully process any Exception subclass that has the requisite
> attributes.
>
> (The caveat, of course, being that the current language may not be
> powerful enough to support such a feature, since implementing the catch
> block sig constraints will require runtime ducktyping.)
>
>
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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141007/f063675c/attachment-0001.html>