Re: [X10-core] X10 2.3 exception hierarchy

[Mikio T. <mik...@gm...>]

Hi, Dave,

As I told you yesterday in the Sametime chat, there is an issue to
make CheckedThrowable NativeRep'ed to java.lang.Throwable.
Since j.l.Throwable is a direct child of j.l.Object, it must be a
direct child of Any. However, it is a child of x.l.Object in the
proposed hierarchy.

I think there are three possible options to implement CheckedThrowable.

1. If we can remove Object, it is the best.

2. If it (i.e. removal of Object) is not acceptable, if
CheckedThrowable is a direct child of Any, it is OK.

3. If it (i.e. making CheckedThrowable direct child of Any) is not
acceptable, we need to box CheckedThrowable to something that
implements x10.core.RefI (to which x.l.Object is NativeRep'ed). As I
told you, this already happens with x.l.String so the logic is already
there.

I wonder the Option 3 is has the least impact to the existing code.
However if we remove Object, it is the best chance.  Please discuss
with Vijay and the team and let me know their decision.

-- Mikio


2012/7/19 David Cunningham <dc...@us...>:
> Just had a discussion with Dave Grove about what to do about Exception,
> Throwable, etc.  It somewhat makes my last email obsolete, so I'll resay the
> relevant parts from scratch.  Also spoke with Vijay who is OK with these
> changes.
>
>
> The simple back story is we want the exception hierarchy in X10 to be
> symmetrical with Java.  We want best practices for programming with
> exceptions in X10 to be as similar as possible to Java, up to the switch to
> preferring unchecked exceptions.  We want the names of the classes to be
> sensible as well.
>
>
> Backwards incompatible changes:
>
> The first change is that the root (Throwable) is checked rather than
> unchecked.  We will thus name it CheckedThrowable.  Throwable no-longer
> exists in the language.
>
> The second change is the introduction of a new class CheckedException, which
> is the root of all exceptions (including checked ones) that are not under
> Error.
>
> The third change is the squashing of RuntimeException and Exception to a
> single class called Exception.  This makes sense because Exception is
> unchecked in X10 so the distinction between these two classes in Java does
> not exist in X10.
>
>
> Red means checked, green means unchecked
>
> Old X10 hierarchy:
> x10.lang.Throwable
>         x10.lang.Exception
>                 x10.lang.RuntimeException
>                         NPE, CCE, ABIE, SBIE, etc
>                 x10.io.Exception, etc
>         x10.lang.Error
>                 OOME, x10.lang.AssertionError
>
>
> Java hierarchy
> java.lang.Throwable
>         java.lang.Exception
>                 java.lang.RuntimeException
>                         NPE, CCE, ABIE, SBIE, etc
>                 java.io.Exception, etc
>         java.lang.Error
>                 OOME, java.lang.AssertionError
>
>
> New X10 hierarchy (classes only visible in managed backend are shown in
> parens)
> x10.lang.CheckedThrowable
>         x10.lang.CheckedException
>                 x10.lang.Exception
>                         NPE, CCE, ABIE, SBIE, etc
>                         x10.io.IOException, etc
>                         (Any java class that extends
> java.lang.RuntimeException, e.g. java.lang.ArrayStoreException)
>                 (Any  java class that extends java.lang.Exception, e.g.
> java.io.IOException)
>         x10.lang.Error
>                 OOME, x10.lang.AssertionError
>                 (Any java class that extends java.lang.Error, e.g.
> java.lang.StackOverflowException)
>
> The New X10 hierarchy is the same as the Java hierarchy, but with some
> classes renamed.  This makes interop and java codegen very simple.  None of
> the mapped Java classes (e.g. java.lang.Throwable) are accessible via
> interop, one must use the X10 names.  Exception stack traces printed by X10
> code or by the X10 runtime will use the X10 names.
>
>
>
>
> Migration advice and best practices for new X10 exception hierarchy
>
> If you prreviously extended Throwable, you should modify your code to extend
> Exception or Error instead.  The distinction between Exception and Error in
> X10 is the same as that between Exception and Error in java.
> * Extend Error for internal application errors that should be immediately
> propagated to the user, either to provide useful bug reporting information
> (i.e. the stack trace), or because handling of the error without exiting the
> application is not possible.
> * Extend Exception when the exception could reasonably be handled by the
> application, e.g. by showing the user a more comprehensible error message,
> or by transparently ignoring a configuration file that could not be read.
>
> If you were catching Throwable, you should either
> * catch Exception, if you want to handle the exception without propagating
> it to the user, i.e. let exceptions under Error fall through your catch
> statement
> * catch Exception and Error (in separate catch blocks), if the catch is for
> preserving the integrity of your state during exceptional control flow, e.g.
> releasing a lock, closing a file, etc.  These exceptions are typically
> rethrown.
> * catch CheckedException if you want to catch all checked exceptions (e.g.
> if you call a method that has a throws CheckedException annotation).  You
> cannot rethrow such exceptions without a throws annotation on your method,
> but you can package them and rethrow.
> * catch CheckedThrowable, if you want to catch everything.  You cannot
> rethrow a caught exception without the throws CheckedThrowable annotation on
> your method.
>
> If you were extending RuntimeException, you should extend Exception instead.
>
> If you were catching RuntimeException, catch Exception instead.
>
> Most people should define a new exception by extending Exception.  The X10
> standard library and other libraries from the X10 team will only throw
> exceptions under Exception.
>
> If you want an exception that should bypass most user exception handling,
> extend Error.
>
> If for some reason you want a checked exception in X10, extend
> CheckedException.  Do not extend Throwable, unless for some reason you want
> your exception to be uncaught by user code that catches Error and
> CheckedException.  Note that closures cannot throw checked exceptions or
> call methods with throws annotations, which limits the usefulness of checked
> exceptions.
>
> All exceptions work as expected in an at clause.
>
> Any exception that reaches the root of an async and is not under
> x10.lang.Exception will be wrapped as it is inserted into the
> MultipleExceptions object.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> X10-core mailing list
> X10...@li...
> https://lists.sourceforge.net/lists/listinfo/x10-core
>