From: Mikio T. <mik...@gm...> - 2012-07-19 08:06:29
|
Hi Dave, Please use the attached slides for the discussion. -- Mikio 2012/7/19 Mikio Takeuchi <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 >> |