From: Mikio T. <mik...@gm...> - 2012-08-30 13:27:43
|
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 lis...@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 |