Mailing-List: contact dev-help@systemml.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@systemml.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <201604030434.u334YiEN024835@d01av04.pok.ibm.com>
References: <201604030434.u334YiEN024835@d01av04.pok.ibm.com>
Date: Mon, 4 Apr 2016 14:38:22 -0700
Message-ID: 
 <CAO1aQR_cAt+CH88djAwMMjYGr7SVnmSCL=aXi+2NUXov5gVsuA@mail.gmail.com>
Subject: Re: Discussion SYSTEMML-593 MLContext Resign
From: Deron Eriksson <deroneriksson@gmail.com>
To: dev@systemml.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a1135de7e4596f7052faf8c4b

--001a1135de7e4596f7052faf8c4b
Content-Type: text/plain; charset=UTF-8

Hi Matthias,


On Sat, Apr 2, 2016 at 9:34 PM, Matthias Boehm <mboehm@us.ibm.com> wrote:

>
> Also rather than introducing another exception class, couldn't we just
> reuse DMLException by making it an uncaught exception?
>

Thank you for the feedback. My thoughts for creating an uncaught
MLContextException center around a few issues:

1) The exception happens through the MLContext API, so to me the naming
makes sense.

2) Placement of the new exception is in a org.apache.sysml.api.mlcontext
package, along with all other primary classes that the user interacts with
when using the MLContext API. This standardization is useful for things
such as Javadocs (all API classes are under this single package) and code
maintainability (all primary API classes are centralized in a single place).

3) This exception would handle errors that happen at the MLContext level
and additionally be a wrapper for deeper levels of exceptions.

4) The naming of DMLException can be confusing to an end user. If a user
runs PyDML and gets a DMLException, this is a little disconcerting.

5) It seems to me the cleanest least-invasive solution that gives the user
the simplest experience is a new runtime exception. Given the
interrelations of existing exception classes, almost all of which are
actually caught exceptions, a new runtime exception avoids any retrofitting
needed of existing exception handling. In the MLContext API, you just catch
all existing caught exceptions and rethrow as MLContextExceptions, or
generate new MLContextExceptions where appropriate.

Throwable
|-Exception
  |-DMLException (323 matches)
    |-AppException (not used)
    |-DMLDebuggerException (13 matches)
    |-DMLRuntimeException (3,689 matches)
      |-CacheException (82 matches)
        |-CacheIOException (26 matches)
        |-CacheStatusException (18 matches)
      |-DMLScriptException (39 matches)
    |-DMLUnsupportedOperationException (1,068 matches)
    |-HopsException (748 matches)
    |-LanguageException (390 matches)
    |-LopsException (596 matches)
  |-ParseException (320 matches)
    |-DMLParseException (50 matches)
  |-RuntimeException
    |-PackageRuntimeException (70 matches)

Since there are already 15 existing exception classes, adding an additional
exception class for a programmatic API doesn't seem to me to be an
unnecessary proliferation of classes.

Deron

--001a1135de7e4596f7052faf8c4b--