| Xcore codegen problem with operations throwing exceptions [message #892691] |
Fri, 29 June 2012 04:47  |
Eclipse User |
|
|
|
Hi all,
I just downloaded Juno and I am trying out Xcore. I like its cool new
features. However, I discovered the following problem: I have an
operation in my xcore model, which throws an exception. The exception
is my own class inheriting from java.lang.Exception. In the generated
Java code, a compile problem is detected in the eInvoke() operation
because it does not declare to throw that exception, it only declares
InvocationTargetException. Adding my own exception here is a bad idea,
of course, and also not possible because the signature is defined in
BasicEObjectImpl. Are there already solutions for this problem? My
current workaround is inheriting from RuntimeException.
Best regards,
Stephan
|
|
|
| Re: Xcore codegen problem with operations throwing exceptions [message #892834 is a reply to message #892691] |
Sat, 30 June 2012 02:56  |
| Eclipse User |
|
|
|
Stephan,
Oh, that's an old problem that was clearly overlooked in the templates
themselves. We really should, for the case of an EOperation that has
eExceptions (or maybe in general, though we can't generally know it's a
checked exception or now), generate a try block that catches the
exception and wraps it properly.
Please open a bugzilla.
On 29/06/2012 10:47 AM, Stephan Hildebrandt wrote:
> Hi all,
>
> I just downloaded Juno and I am trying out Xcore. I like its cool new
> features. However, I discovered the following problem: I have an
> operation in my xcore model, which throws an exception. The exception
> is my own class inheriting from java.lang.Exception. In the generated
> Java code, a compile problem is detected in the eInvoke() operation
> because it does not declare to throw that exception, it only declares
> InvocationTargetException. Adding my own exception here is a bad idea,
> of course, and also not possible because the signature is defined in
> BasicEObjectImpl. Are there already solutions for this problem? My
> current workaround is inheriting from RuntimeException.
>
> Best regards,
>
> Stephan
|
|
|
Powered by
FUDForum. Page generated in 0.03568 seconds
Home