systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Boehm" <mbo...@us.ibm.com>
Subject Re: Discussion SYSTEMML-593 MLContext Resign
Date Tue, 05 Apr 2016 05:07:34 GMT

Thanks Deron - those are all valid arguments. However, the summary of
exceptions actually makes a good case for cleaning up the entire exception
handling. I created SYSTEMML-616 to track this. Let's decide on MLContext
once this is done.

Regards,
Matthias




From:	Deron Eriksson <deroneriksson@gmail.com>
To:	dev@systemml.incubator.apache.org
Date:	04/04/2016 02:38 PM
Subject:	Re: Discussion SYSTEMML-593 MLContext Resign



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


Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message