Menu
▾
▴
Re: [X10-core] Porting notes for X10 2.3
|
From: David C. <dc...@us...> - 2012-08-30 19:46:06
|
I should have included an example like the following for the new syntaxes:
f has a method guard T isref, takes a T, returns a T, and also throws
CheckedThrowable
public class XTEN_2_3 {
public static def f[T](x:T) { T isref } : T throws CheckedThrowable =
x;
public static def main (args : Rail[String]) {
try {
f(new String());
//f(42); // error -- Int isref inconsistent
} catch (e:CheckedThrowable) { // type system requires we catch
here
e.printStackTrace();
}
}
}
Mikio Takeuchi <mik...@gm...> wrote on 08/30/2012 09:27:23 AM:
> From: Mikio Takeuchi <mik...@gm...>
> To: "vi...@sa..." <vi...@sa...>
> Cc: "x10...@li..." <x10...@li...>
> Date: 08/30/2012 09:27 AM
> Subject: Re: [X10-core] Porting notes for X10 2.3
>
> Hi, Vijay.
>
> We implemented throws clause just as Java. @Throws[T] annotation was
gone.
>
> - Mikio
>
> On Aug 30, 2012, at 21:33, Vijay Saraswat <vi...@sa...> wrote:
> Thanks a lot, Dave and Mikio!
>
> A quick question.. what is the syntax for declaring a method throws
> an exception? (not sure how to interprete "annotation", could be a
> throws clause or could be a genuine annotation. what did you implement.)
>
> On 8/29/12 11:24 PM, David Cunningham wrote:
> We just merged the interop-exceptions branch into trunk, and this
> carries with it a number of changes (that are not backwards
> compatible) to allow cleaner Java interoperability for the managed
> backend. You will probably have to make some minor adjustments to
> your X10 code if you intend to compile it using trunk X10, or the
> forthcoming X10 2.3 release.
>
>
> The new syntax T isref for some type T will hold if T is represented
> by a pointer at runtime. This is similar to the type constraint T
> haszero. T isref is true for T that are function types, classes,
> and all values that have been cast to interfaces (including boxed
> structs). T isref is used in the standard library, e.g. for the
> GlobalRef[T] and PlaceLocalHandle[T] APIs.
>
>
> x10.lang.Object is gone, there is now no single class that is the
> supertype of all classes.
>
> If, for some reason, you were extending Object, don't do that anymore.
>
> If you were doing new Object() to get a fresh value, use new Empty()
instead.
>
> If you were using Object as a supertype, use Any (the one true
supertype).
>
> If you were using the type constraint T <: Object to disallow
> structs, use T isref instead.
>
>
> The exception hierarchy has changed, and checked exceptions have
> been reintroduced. The 'throws' annotation is required on methods,
> as in Java. It is not supported on closures, so checked exceptions
> cannot be thrown from a closure. The exception hierarchy has been
> chosen to exist in a 1:1 relationship with Java's. However, unlike
> Java, we prefer using unchecked exceptions wherever possible, and
> this is reflected in the naming of the X10 classes. The following
> classes are all in the x10.lang package.
>
> CheckedThrowable (mapped to java.lang.Throwable)
> \-- CheckedException (mapped to java.lang.Exception)
> \-- Exception (mapped to java.lang.RuntimeException)
> \-- Error (mapped to java.lang.Error)
>
> Anything under CheckedThrowable can be thrown using the throw
> statement... But anything that is not under Exception or Error can
> only be thrown if it is caught by an enclosing try/catch, or it is
> thrown from a method with an appropriate throws annotation, as in Java.
>
> RuntimeException is gone from X10. Use Exception instead.
>
> All the exceptions in the standard library are under Exception,
> except AssertionError and OutOfMemoryException, which are under
> Error (as in Java). This means all exceptions in the standard
> library remain unchecked.
>
> Note that catching Exception is not sufficient to catch
> AssertionError or OutOfMemoryException. To handle all unchecked
> exceptions, one must catch Exception and Error in separate catch
> blocks, catch CheckedThrowable in a single catch block, or use a
> finally block. This is the same as Java.
>
> Best practice is to derive from Exception for your own X10 exception
> classes, in which case no throws annotations are needed anywhere in
> your X10 code. If you write X10 code that interoperates with Java,
> you may have to deal with checked exceptions such as
> java.io.IOException in your X10 code. This is when you may consider
> using throws annotations.
>
> We also provide an exception x10.lang.WrappedThrowable under
> Exception, that can be used to wrap a given CheckedThrowable using
> the exception chaining mechanism (getCause()) if it is not already a
> subtype of Exception. This can be useful for handling arbitrary
> exceptions coming from Java code, at the boundary with X10, forcing
> them into more X10-friendly exceptions that are under
x10.lang.Exception.
>
> // rethrow a checked exception (or an Error) as an Exception by
> wrapping it in WrappedThrowable if necessary
> try {
> assert false;
> } catch (t:CheckedThrowable) { throw Exception.ensureException(t); }
>
> Checked exceptions and Errors are cleanly propagated through 'at'
> blocks just like any other exception.
>
> Checked exceptions and Errors are wrapped in WrappedThrowable at the
> root of an async, when they are pushed into a MultipleExceptions
> object. Therefore only Exception objects can come out of a
> MultipleExceptions object.
>
>
> With all this in mind, here is some porting advice for exceptions in 2.3
>
> If you previously extended Throwable, extend Exception instead.
>
> If you previously extended RuntimeException, extend Exception instead.
>
> If you previously extended Error, do some soul searching to decide
> whether you want your exception to be caught by 'catch
> (e:Exception)' or not. You probably should be extending Exception
instead.
>
> If for some reason you really want to use checked exceptions in X10,
> you can extend CheckedException. But we don't recommend this as the
> throws annotation is not supported in function types. You're
> probably making your life harder, not easier.
>
> If you previously caught Throwable, you need to change to one of these:
>
> try { ... } catch (e:CheckedThrowable) { ... }
> try { ... } catch (e:Exception) { ... } catch (e:Error) { ... }
>
> If you want to catch everything and do e.printStackTrace(), then
> catching CheckedThrowable is a good choice. However if you are
> catching to rethrow, this will force you to include a throws
> CheckedThrowable annotation on your method, and any methods that
> transitively call it. You probably don't want that.
>
> If you want to rethrow everything but you only care about unchecked
> exceptions, e.g. you need to close a file or release a lock or some
> other 'end of work' bureaucracy around code that may throw
> exceptions, then you can use a finally block, or catch both Error
> and Exception (duplicating your handling code) and rethrow these
> exceptions without needing a throws annotation on your method.
>
> You can also catch (e:CheckedThrowable) and use
> Exception.ensureException(e) to wrap it when you rethrow it, but
> this will obviously be caught as a WrappedThrowable instead of the
> original exception, which is probably not what you want.
>
> Of course if you were actually catching a particular exception, e.g.
> to implement some exciting control flow such as jumping out from the
> middle of a recursive call stack, then catch that specific type.
>
>
> Hope this helps.
>
------------------------------------------------------------------------------
> 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
|