From: David C. <dc...@us...> - 2012-07-17 21:13:00
|
Time is tight, but we can punt some of this stuff. These must be done before the release: Syntax change: @Throws -> throws (few days of work in the type system and parser) Hierarchy change: Add CheckedThrowable. Implement in java by @NativeRep throwable. Put x.l.T under it. Make appropriate changes to c++ native code. Put x.l.Error under x.l.CheckedThrowable. Type system modifications (can throw checked throwable, etc) Maybe get rid of x.l.Exception? Definitely get rid of x.l.RuntimeException (probably a couple of weeks work here) Make XRX transparently propagate Error properly through async/finish Make XRX transparently propagate CheckedThrowable through at (complex implementation, described in previous email) (a few days to a week) If we do not do the following before the release, we can write them up as limitations (i.e. don't write code that requires the correct behaviour) Disable exception wrapping in managed backend. NativeRep exceptions to java equivalents. x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, Change assert codegen to throw x10.lang.AssertionError instead of java.lang.AssertionError (probably less than a week) Fix printStackTrace and related functions to rewrite to x10 exception names. (should only take a couple of days) |
From: Mikio T. <mik...@gm...> - 2012-07-18 06:46:45
|
I got rid of x.l.RuntimeException in r24107. I will also take care of the change of Java codegen for assertions. -- Mikio 2012/7/18 David Cunningham <dc...@us...>: > Time is tight, but we can punt some of this stuff. > > > These must be done before the release: > > Syntax change: > @Throws -> throws > (few days of work in the type system and parser) > > Hierarchy change: > Add CheckedThrowable. > Implement in java by @NativeRep throwable. Put x.l.T under it. Make > appropriate changes to c++ native code. > Put x.l.Error under x.l.CheckedThrowable. > Type system modifications (can throw checked throwable, etc) > Maybe get rid of x.l.Exception? > Definitely get rid of x.l.RuntimeException > (probably a couple of weeks work here) > > Make XRX transparently propagate Error properly through async/finish > Make XRX transparently propagate CheckedThrowable through at (complex > implementation, described in previous email) > (a few days to a week) > > > If we do not do the following before the release, we can write them up as > limitations (i.e. don't write code that requires the correct behaviour) > > Disable exception wrapping in managed backend. > NativeRep exceptions to java equivalents. > x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, > Change assert codegen to throw x10.lang.AssertionError instead of > java.lang.AssertionError > (probably less than a week) > > Fix printStackTrace and related functions to rewrite to x10 exception names. > (should only take a couple of days) > > > > ------------------------------------------------------------------------------ > 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 > |
From: Mikio T. <mik...@gm...> - 2012-07-18 09:42:27
|
I changed assert codegen to throw x10.lang.AssertionError instead of java.lang.AssertionError in r24108 (trunk) and r24109 (java-interop-exceptions branch). -- Mikio 2012/7/18 Mikio Takeuchi <mik...@gm...>: > I got rid of x.l.RuntimeException in r24107. > I will also take care of the change of Java codegen for assertions. > -- Mikio > > 2012/7/18 David Cunningham <dc...@us...>: >> Time is tight, but we can punt some of this stuff. >> >> >> These must be done before the release: >> >> Syntax change: >> @Throws -> throws >> (few days of work in the type system and parser) >> >> Hierarchy change: >> Add CheckedThrowable. >> Implement in java by @NativeRep throwable. Put x.l.T under it. Make >> appropriate changes to c++ native code. >> Put x.l.Error under x.l.CheckedThrowable. >> Type system modifications (can throw checked throwable, etc) >> Maybe get rid of x.l.Exception? >> Definitely get rid of x.l.RuntimeException >> (probably a couple of weeks work here) >> >> Make XRX transparently propagate Error properly through async/finish >> Make XRX transparently propagate CheckedThrowable through at (complex >> implementation, described in previous email) >> (a few days to a week) >> >> >> If we do not do the following before the release, we can write them up as >> limitations (i.e. don't write code that requires the correct behaviour) >> >> Disable exception wrapping in managed backend. >> NativeRep exceptions to java equivalents. >> x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, >> Change assert codegen to throw x10.lang.AssertionError instead of >> java.lang.AssertionError >> (probably less than a week) >> >> Fix printStackTrace and related functions to rewrite to x10 exception names. >> (should only take a couple of days) >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> |
From: Mikio T. <mik...@gm...> - 2012-07-18 10:30:13
|
I have some questions and comments. 2012/7/18 David Cunningham <dc...@us...>: > Maybe get rid of x.l.Exception? What is this? > Definitely get rid of x.l.RuntimeException Done. > Disable exception wrapping in managed backend. > NativeRep exceptions to java equivalents. > x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, To use NativeRep to java equivalents, we basically not able to change the type hierarchy. For example, the super type of x10.lang.NullPointerException, which is java.lang.NullPointerException in generated Java code, will be java.lang.RuntimeException. We may be able to skip j.l.RuntimeException and treat it as a single leaf child of x10.lang.Exception by modifying RuntimeType and the families, but it requires manual modification and drastic change of the exception hierarchy from Java is not realistic. > Change assert codegen to throw x10.lang.AssertionError instead of > java.lang.AssertionError This is also done. -- Mikio |
From: David C. <dc...@us...> - 2012-07-18 17:35:05
|
Good to see your progress. I will look at reintroducing throws again today. > > Maybe get rid of x.l.Exception? > > What is this? Probably not what it was, or no-longer what it was meant to be :) In java java.lang.Exception should probably be called 'NotError' i.e. exceptions are either under Error or Exception. If you want to catch everything except Error you can catch Exception. But x10.lang.Throwable fits this role precisely already, leaving x.l.Exception to be just as pointless as x.l.RuntimeException. The x10doc for x10.l.Throwable should probably be changed to be based on the current x10doc for x10.lang.RuntimeException. "The class Throwable and its subclasses are an unchecked form of CheckedThrowable that indicate conditions that a reasonable application might want to catch." I think there is a strong case for actually renaming x.l.Throwable to x.l.Exception since Java programmers might expect Throwable to be the root and Exception to be 'most exceptions'. We then have CheckedThrowable, which looks a lot like the familiar Throwable, and no other mention of Throwable anywhere. The changes to names (Throwable->CheckedThrowable, RuntimeException->Exception) would be pretty much what one would expect if the only difference between X10 and Java is the inversion of the default checkedness of exceptions (which *is* pretty much the only difference at this point). > > Disable exception wrapping in managed backend. > > NativeRep exceptions to java equivalents. > > x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, > > To use NativeRep to java equivalents, we basically not able to change > the type hierarchy. > For example, the super type of x10.lang.NullPointerException, which is > java.lang.NullPointerException in generated Java code, will be > java.lang.RuntimeException. We may be able to skip > j.l.RuntimeException and treat it as a single leaf child of > x10.lang.Exception by modifying RuntimeType and the families, but it > requires manual modification and drastic change of the exception > hierarchy from Java is not realistic. I agree the type hierarchies have to match. We can add new subtrees to any class in java that is not final, and we can omit nodes in the type hierarchy by 'skipping over them' in X10. We cannot however add a new class between A and B if A and B already exist in Java. I don't think we can do any tricks with runtime types because we need the fundamental subtype relationship in java to be compatible with the X10 one if we want to re-use its object model. Otherwise, we cannot upcast NPE to RuntimeException (without some sort of implicit conversion that breaks ==). It follows that we must have x.l.NPE extends j.l.T as you say. We don't have to kill x.l.Exception, we can just move all the important classes to be under x.l.Throwable. Anyone caring about NPE etc are very likely to be catching Throwable, not Exception. If not, they have to do some find/replace. As for the fate of x.l.Exception we have lots of options I think: 1) Kill it, tell people to find/replace Exception to Throwable in their X10 code. 2) Kill it and replace it with a deprecated typedef. Don't use it in XRX or M3R. 3) Leave it as a weird class on the site but deprecate it. Don't use it in XRX or M3R. 4) Leave it as a weird class on the site but tell people that catching it is a bad idea because it doesn't include a lot of exceptions that people will want to catch. 5-6) As 1 and 2, but rename x10.lang.Throwable to x10.lang.Exception and have x10.lang.Throwable be the class that disappears / is typedeffed. I'll try to sketch out the hierarchies here: j.l.Throwable (1) - j.l.Exception (not represented in X10) -- j.l.RuntimeException (2) --- j.l.NullPointerException --- j.l.ClassCastException --- j.l.ArrayBoundsIndexException --- j.l.StringBoundsIndexException -- j.l.Error (3) --- j.l.OutOfMemoryException x.l.CheckedThrowable (1) - x.l.Throwable (2) (perhaps renamed to x.l.Exception) -- x.l.NullPointerException -- x.l.ClassCastException -- x.l.ArrayBoundsIndexException -- x.l.StringBoundsIndexException - x.l.Error (3) -- x.l.OutOfMemoryException (There are additional types in the x10 hierarchy, under x.l.T, but we don't have to worry about those as they are not NativeRepped to java exceptions) (There are additional types in the java hierarchy, but we don't have to worry about them because they are exposed simply via interop and won't appear in code that doesn't use interop) |
From: Mikio T. <mik...@gm...> - 2012-07-19 07:37:20
|
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 > |
From: Mikio T. <mik...@gm...> - 2012-07-19 08:06:29
Attachments:
managedx10typehierarchy-20120719.ppt
|
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 >> |
From: Mikio T. <mik...@gm...> - 2012-07-18 17:31:50
|
For the change of type hierarchy, please send me the new hierarchy (something like Figure 3.3 in my Managed X10 users guide) so that I can prepare for the change in RTT and codegen side. thanks. -- Mikio On Jul 18, 2012, at 6:13, David Cunningham <dc...@us...> wrote: Time is tight, but we can punt some of this stuff. *These must be done before the release:* Syntax change: @Throws -> throws (few days of work in the type system and parser) Hierarchy change: Add CheckedThrowable. Implement in java by @NativeRep throwable. Put x.l.T under it. Make appropriate changes to c++ native code. Put x.l.Error under x.l.CheckedThrowable. Type system modifications (can throw checked throwable, etc) Maybe get rid of x.l.Exception? Definitely get rid of x.l.RuntimeException (probably a couple of weeks work here) Make XRX transparently propagate Error properly through async/finish Make XRX transparently propagate CheckedThrowable through at (complex implementation, described in previous email) (a few days to a week) *If we do not do the following before the release, we can write them up as limitations (i.e. don't write code that requires the correct behaviour)* Disable exception wrapping in managed backend. NativeRep exceptions to java equivalents. x.l.Throwable, NPE, ClassCast, ArrayBounds, StringBounds, Change assert codegen to throw x10.lang.AssertionError instead of java.lang.AssertionError (probably less than a week) Fix printStackTrace and related functions to rewrite to x10 exception names. (should only take a couple of days) ------------------------------------------------------------------------------ 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 |
From: David C. <dc...@us...> - 2012-07-18 23:58:01
|
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. |
From: David C. <dc...@us...> - 2012-07-19 20:52:06
|
OK, we had the discussion (Avi, Vijay, Dave Grove, me) Current plan is to 1) remove Object 2) add an isref keyword, that can be used in constraints like haszero to indicate that a type is not a struct isref will be used anywhere where <:Object is currently used, e.g. GlobalRef PlaceLocalHandle and some others (Deque?) Classes that do not specify a parent will have default implementations of typeName() equals() toString() hashCode(), perhaps through extending RefI although RefI is no longer visible to the x10 programmer. Another option is to simply generate such methods in every generated java class. Going off on a slight tangent, it would be nice if X10 classes that extend java classes have default implementations of typeName and friends provided that are similar to the ones in RefI. And a small status update: I have almost finished adding throws back into the exceptions branch. Just ironing out some bugs. Mikio Takeuchi <mik...@gm...> wrote on 07/19/2012 03:37:11 AM: > From: Mikio Takeuchi <mik...@gm...> > To: X10 core design <x10...@li...>, > Date: 07/19/2012 03:37 AM > Subject: Re: [X10-core] X10 2.3 exception hierarchy > > 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'llresay 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 codeto 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 > > > > ------------------------------------------------------------------------------ > 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 > |
From: Mikio T. <mik...@gm...> - 2012-07-20 03:52:54
|
Good to hear that Object will be removed. Thanks, -- Mikio 2012/7/20 David Cunningham <dc...@us...>: > OK, we had the discussion (Avi, Vijay, Dave Grove, me) > > Current plan is to > > 1) remove Object > 2) add an isref keyword, that can be used in constraints like haszero to > indicate that a type is not a struct > > isref will be used anywhere where <:Object is currently used, e.g. > > GlobalRef > PlaceLocalHandle > > and some others (Deque?) > > Classes that do not specify a parent will have default implementations of > typeName() equals() toString() hashCode(), perhaps through extending RefI > although RefI is no longer visible to the x10 programmer. Another option is > to simply generate such methods in every generated java class. > > Going off on a slight tangent, it would be nice if X10 classes that extend > java classes have default implementations of typeName and friends provided > that are similar to the ones in RefI. > > > And a small status update: I have almost finished adding throws back into > the exceptions branch. Just ironing out some bugs. > > > Mikio Takeuchi <mik...@gm...> wrote on 07/19/2012 03:37:11 AM: > >> From: Mikio Takeuchi <mik...@gm...> >> To: X10 core design <x10...@li...>, >> Date: 07/19/2012 03:37 AM >> Subject: Re: [X10-core] X10 2.3 exception hierarchy >> >> 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'llresay >> > 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 codeto >> > 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 >> > >> >> >> ------------------------------------------------------------------------------ >> 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 >> > > ------------------------------------------------------------------------------ > 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 > |