Home » Modeling » EMF » Exception is not handled by the provider classes of the generated Edit plugin
| | |
| Re: Exception is not handled by the provider classes of the generated Edit plugin [message #417571 is a reply to message #417565] |
Fri, 14 March 2008 23:27   |
 Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
> exception? What happens in the generated eGet method? I guess that's
> okay because the generated method in the implementation
> doesn't actually thrown an exception?
exactly - that's the case.
The actual case is, that the "getName() throws
javax.jcr.RepositoryException" method comes from the interface of the
JSR-170 (Java Content Repository) specification so I cannot do something
about it. I guess the exception is comparable to a general SQLException
and will inform about things like a lost connection to the repository.
The JavaDoc [1] doesn't say anything special about it.
The goal of JCRM is, to provide a meta model that is based on JSR-170
including a storage mechanism (an EStore implementation). Users are able
to create an own domain model and refer to the meta model e.g. by
changing some of their .genmodel properties.
This way they should get their complete editor for their specific domain
that is backed by a Java Content Repository by just clicking "generate
All". At the moment it looks like it can work like that except that they
would need to handle the exceptions in their generated edit plugin
manually. I will have a look into the EMF code generation and how
practical it is to enhance it without forking it for JCRM.
>How is a user really supposed to use an API like this?
He should get a dialog box saying something like "Repository connection
lost. Please try to reconnect if the repository is available again."
Ciao,
Sandro
[1] -
http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/I tem.html#getName()
Ed Merks schrieb:
> Sandro,
>
> Accessors are never generated to throw an exception (there's no way to
> declare that for an EStructuralFeature in Ecore) so we really won't
> expect something like this. Does it really make all that much sense
> that any access of the name feature can throw an arbitrary checked
> exception? What happens in the generated eGet method? I guess that's
> okay because the generated method in the implementation doesn't actually
> thrown an exception? How is a user really supposed to use an API like
> this? If it were a RuntimeException, at least you wouldn't have to
> check it. That would seem more reasonable...
>
>
> Sandro Böhme wrote:
>> Hello again,
>>
>> just to make it more explicit and easier to reproduce here is an
>> annotated java source that matches the scenario:
>>
>> ============================================================ ==
>> package mypackage;
>>
>> import org.eclipse.emf.ecore.EObject;
>> /**
>> * @model
>> */
>> public interface MyClass extends EObject {
>> /**
>> * @model
>> */
>> public String getName() throws Exception;
>> }
>> ============================================================ ==
>> If one generates the .genmodel from that annotated java source,
>> generates the model and finally the edit plugin one see the compile
>> error. Is that case designed to be handled by the code generation
>> framework?
>> Thanks in advance for any help.
>>
>> Bye,
>>
>> Sandro
>>
>> Sandro Böhme schrieb:
>>> Hello,
>>>
>>> I have basically an EClass that has a name attribute. This attribute
>>> throws an Exception. If I generate the Edit plugin from this model it
>>> does not handle the Exception. E.g. catching it or throwing it to the
>>> UI. The problem is located in the getText(Object object) method of
>>> the provider class. By default it uses the name attribute to display
>>> the label of the model-item.
>>>
>>> Is there any possibility to configure the model that the Edit plugin
>>> gets generated in a way that handles the Exception? Or do I need to
>>> handle the Exception after the generation manually?
>>> Any hint is much appreciated.
>>>
>>> Thanks,
>>>
>>> Sandro
|
|
|
| Re: Exception is not handled by the provider classes of the generated Edit plugin [message #417572 is a reply to message #417571] |
Fri, 14 March 2008 23:42 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
> manually. I will have a look into the EMF code generation and how
> practical it is to enhance it without forking it for JCRM.
Ahh - I've seen that the .genmodel contains "Provider Root Extends
Class". There really is a hook everywhere in EMF eh ;-). I will see
later if that solves my problem.
Ciao,
Sandro
Sandro Böhme schrieb:
> Hi Ed,
>
> > exception? What happens in the generated eGet method? I guess that's
> > okay because the generated method in the implementation
> > doesn't actually thrown an exception?
> exactly - that's the case.
>
> The actual case is, that the "getName() throws
> javax.jcr.RepositoryException" method comes from the interface of the
> JSR-170 (Java Content Repository) specification so I cannot do something
> about it. I guess the exception is comparable to a general SQLException
> and will inform about things like a lost connection to the repository.
> The JavaDoc [1] doesn't say anything special about it.
>
> The goal of JCRM is, to provide a meta model that is based on JSR-170
> including a storage mechanism (an EStore implementation). Users are able
> to create an own domain model and refer to the meta model e.g. by
> changing some of their .genmodel properties.
> This way they should get their complete editor for their specific domain
> that is backed by a Java Content Repository by just clicking "generate
> All". At the moment it looks like it can work like that except that they
> would need to handle the exceptions in their generated edit plugin
> manually. I will have a look into the EMF code generation and how
> practical it is to enhance it without forking it for JCRM.
>
> >How is a user really supposed to use an API like this?
> He should get a dialog box saying something like "Repository connection
> lost. Please try to reconnect if the repository is available again."
>
> Ciao,
>
> Sandro
>
> [1] -
> http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/I tem.html#getName()
>
>
>
> Ed Merks schrieb:
>> Sandro,
>>
>> Accessors are never generated to throw an exception (there's no way to
>> declare that for an EStructuralFeature in Ecore) so we really won't
>> expect something like this. Does it really make all that much sense
>> that any access of the name feature can throw an arbitrary checked
>> exception? What happens in the generated eGet method? I guess that's
>> okay because the generated method in the implementation doesn't
>> actually thrown an exception? How is a user really supposed to use an
>> API like this? If it were a RuntimeException, at least you wouldn't
>> have to check it. That would seem more reasonable...
>>
>>
>> Sandro Böhme wrote:
>>> Hello again,
>>>
>>> just to make it more explicit and easier to reproduce here is an
>>> annotated java source that matches the scenario:
>>>
>>> ============================================================ ==
>>> package mypackage;
>>>
>>> import org.eclipse.emf.ecore.EObject;
>>> /**
>>> * @model
>>> */
>>> public interface MyClass extends EObject {
>>> /**
>>> * @model
>>> */
>>> public String getName() throws Exception;
>>> }
>>> ============================================================ ==
>>> If one generates the .genmodel from that annotated java source,
>>> generates the model and finally the edit plugin one see the compile
>>> error. Is that case designed to be handled by the code generation
>>> framework?
>>> Thanks in advance for any help.
>>>
>>> Bye,
>>>
>>> Sandro
>>>
>>> Sandro Böhme schrieb:
>>>> Hello,
>>>>
>>>> I have basically an EClass that has a name attribute. This attribute
>>>> throws an Exception. If I generate the Edit plugin from this model
>>>> it does not handle the Exception. E.g. catching it or throwing it to
>>>> the UI. The problem is located in the getText(Object object) method
>>>> of the provider class. By default it uses the name attribute to
>>>> display the label of the model-item.
>>>>
>>>> Is there any possibility to configure the model that the Edit plugin
>>>> gets generated in a way that handles the Exception? Or do I need to
>>>> handle the Exception after the generation manually?
>>>> Any hint is much appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> Sandro
|
|
| |
| Re: Exception is not handled by the provider classes of the generated Edit plugin [message #417593 is a reply to message #417573] |
Sun, 16 March 2008 17:49 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
> Still, I can't imagine writing an application where every
> method I use for even the most basic of fine grained data access
> requires a try-catch block...
the methods on the javax.jcr.Node for example compare to the methods on
the java.sql.ResultSet [1] in this regard. In the first case all data
access throws at least a RepositoryException and in SQL
java.sql.SQLException is thrown for methods accessing data.
But of course in JCRM try-catch should not be needed for simple model
traversal or something like that. This is why I changed my wrapper class
that all domain classes extend from to not expose the javax.jcr.Node
interface anymore. Now the interfaces do not contain checked exceptions
and I throw a RuntimeException in getName() that contains the checked
exception in the "cause" of the exception. This does cleanly solve the
issue while framework users are still able to receive the exception.
Do you think it makes sense for EMF to display the RuntimeExceptions
thrown in the domain model in a dialog box of the generated editor?
Maybe one could catch them at some general content provider level.
> Perhaps these aren't really like
> attributes (EStructuralFeatures) but more like EOperations with
> exceptions...
A javax.jcr.Node instance can have child nodes and properties.
The child nodes are contained in the parent. The properties can be of
the following types:
o String, InputStream, Long, Double, Date, Boolean
o Name (consists of a namespace and a local name like an XML element)
o Path (is an XPath to a node, it does not ensure referential integrity)
o Reference (contains a reference to an node, it does ensures
referential integrity)
I think this is more like EStructuralFeatures than like EOperations and
writing this makes me wanna implement it in Ecore ;-).
What do you think?
[1] - http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.h tml
Best regards,
Sandro
Ed Merks schrieb:
> Sandro,
>
> It seems to me to be an extremely invasive thing that *all *data access
> must explicitly handle exceptions. What about access to items in a
> list? It would seem far better for it to be a runtime exception that
> can be checked optionally or allowed to percolate to higher levels. Of
> course I don't understand the whole context, so maybe it's an ignorant
> comment. Still, I can't imagine writing an application where every
> method I use for even the most basic of fine grained data access
> requires a try-catch block... Perhaps these aren't really like
> attributes (EStructuralFeatures) but more like EOperations with
> exceptions...
>
>
> Sandro Böhme wrote:
>> Hi Ed,
>>
>> > exception? What happens in the generated eGet method? I guess that's
>> > okay because the generated method in the implementation
>> > doesn't actually thrown an exception?
>> exactly - that's the case.
>>
>> The actual case is, that the "getName() throws
>> javax.jcr.RepositoryException" method comes from the interface of the
>> JSR-170 (Java Content Repository) specification so I cannot do
>> something about it. I guess the exception is comparable to a general
>> SQLException and will inform about things like a lost connection to
>> the repository. The JavaDoc [1] doesn't say anything special about it.
>>
>> The goal of JCRM is, to provide a meta model that is based on JSR-170
>> including a storage mechanism (an EStore implementation). Users are
>> able to create an own domain model and refer to the meta model e.g. by
>> changing some of their .genmodel properties.
>> This way they should get their complete editor for their specific
>> domain that is backed by a Java Content Repository by just clicking
>> "generate All". At the moment it looks like it can work like that
>> except that they would need to handle the exceptions in their
>> generated edit plugin manually. I will have a look into the EMF code
>> generation and how practical it is to enhance it without forking it
>> for JCRM.
>>
>> >How is a user really supposed to use an API like this?
>> He should get a dialog box saying something like "Repository
>> connection lost. Please try to reconnect if the repository is
>> available again."
>>
>> Ciao,
>>
>> Sandro
>>
>> [1] -
>> http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/I tem.html#getName()
>>
>>
>>
>> Ed Merks schrieb:
>>> Sandro,
>>>
>>> Accessors are never generated to throw an exception (there's no way
>>> to declare that for an EStructuralFeature in Ecore) so we really
>>> won't expect something like this. Does it really make all that much
>>> sense that any access of the name feature can throw an arbitrary
>>> checked exception? What happens in the generated eGet method? I
>>> guess that's okay because the generated method in the implementation
>>> doesn't actually thrown an exception? How is a user really supposed
>>> to use an API like this? If it were a RuntimeException, at least you
>>> wouldn't have to check it. That would seem more reasonable...
>>>
>>>
>>> Sandro Böhme wrote:
>>>> Hello again,
>>>>
>>>> just to make it more explicit and easier to reproduce here is an
>>>> annotated java source that matches the scenario:
>>>>
>>>> ============================================================ ==
>>>> package mypackage;
>>>>
>>>> import org.eclipse.emf.ecore.EObject;
>>>> /**
>>>> * @model
>>>> */
>>>> public interface MyClass extends EObject {
>>>> /**
>>>> * @model
>>>> */
>>>> public String getName() throws Exception;
>>>> }
>>>> ============================================================ ==
>>>> If one generates the .genmodel from that annotated java source,
>>>> generates the model and finally the edit plugin one see the compile
>>>> error. Is that case designed to be handled by the code generation
>>>> framework?
>>>> Thanks in advance for any help.
>>>>
>>>> Bye,
>>>>
>>>> Sandro
>>>>
>>>> Sandro Böhme schrieb:
>>>>> Hello,
>>>>>
>>>>> I have basically an EClass that has a name attribute. This
>>>>> attribute throws an Exception. If I generate the Edit plugin from
>>>>> this model it does not handle the Exception. E.g. catching it or
>>>>> throwing it to the UI. The problem is located in the getText(Object
>>>>> object) method of the provider class. By default it uses the name
>>>>> attribute to display the label of the model-item.
>>>>>
>>>>> Is there any possibility to configure the model that the Edit
>>>>> plugin gets generated in a way that handles the Exception? Or do I
>>>>> need to handle the Exception after the generation manually?
>>>>> Any hint is much appreciated.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Sandro
>
>
|
|
|
| Re: Exception is not handled by the provider classes of the generated Edit plugin [message #417594 is a reply to message #417593] |
Sun, 16 March 2008 18:05 |
Sandro Boehme
Messages: 95
Registered: July 2009 |
Member |
|
|
Hi Ed,
the RuntimeExceptions are displayed well in the generated editor if they
occur in the usual generated *Impl classes. But if they are thrown e.g.
in the
"public Object dynamicGet(int dynamicFeatureID)"
method of my implementation of EStoreEObjectImpl or in the
"public void add(InternalEObject eObject, EStructuralFeature feature,
int index, Object value)"
method of my implementation of EStoreEObjectImpl.EStoreImpl there is no
dialog box showing me the RuntimeException. Do I use the EStore in the
wrong way using these methods?
Bye,
Sandro
Sandro Böhme schrieb:
> Hi Ed,
>
>> Still, I can't imagine writing an application where every
>> method I use for even the most basic of fine grained data access
>> requires a try-catch block...
> the methods on the javax.jcr.Node for example compare to the methods on
> the java.sql.ResultSet [1] in this regard. In the first case all data
> access throws at least a RepositoryException and in SQL
> java.sql.SQLException is thrown for methods accessing data.
>
> But of course in JCRM try-catch should not be needed for simple model
> traversal or something like that. This is why I changed my wrapper class
> that all domain classes extend from to not expose the javax.jcr.Node
> interface anymore. Now the interfaces do not contain checked exceptions
> and I throw a RuntimeException in getName() that contains the checked
> exception in the "cause" of the exception. This does cleanly solve the
> issue while framework users are still able to receive the exception.
>
> Do you think it makes sense for EMF to display the RuntimeExceptions
> thrown in the domain model in a dialog box of the generated editor?
> Maybe one could catch them at some general content provider level.
>
>> Perhaps these aren't really like
>> attributes (EStructuralFeatures) but more like EOperations with
>> exceptions...
> A javax.jcr.Node instance can have child nodes and properties.
> The child nodes are contained in the parent. The properties can be of
> the following types:
> o String, InputStream, Long, Double, Date, Boolean
> o Name (consists of a namespace and a local name like an XML element)
> o Path (is an XPath to a node, it does not ensure referential integrity)
> o Reference (contains a reference to an node, it does ensures
> referential integrity)
> I think this is more like EStructuralFeatures than like EOperations and
> writing this makes me wanna implement it in Ecore ;-).
> What do you think?
>
> [1] - http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.h tml
>
> Best regards,
>
> Sandro
>
> Ed Merks schrieb:
>> Sandro,
>>
>> It seems to me to be an extremely invasive thing that *all *data
>> access must explicitly handle exceptions. What about access to items
>> in a list? It would seem far better for it to be a runtime exception
>> that can be checked optionally or allowed to percolate to higher
>> levels. Of course I don't understand the whole context, so maybe it's
>> an ignorant comment. Still, I can't imagine writing an application
>> where every method I use for even the most basic of fine grained data
>> access requires a try-catch block... Perhaps these aren't really like
>> attributes (EStructuralFeatures) but more like EOperations with
>> exceptions...
>>
>>
>> Sandro Böhme wrote:
>>> Hi Ed,
>>>
>>> > exception? What happens in the generated eGet method? I guess that's
>>> > okay because the generated method in the implementation
>>> > doesn't actually thrown an exception?
>>> exactly - that's the case.
>>>
>>> The actual case is, that the "getName() throws
>>> javax.jcr.RepositoryException" method comes from the interface of the
>>> JSR-170 (Java Content Repository) specification so I cannot do
>>> something about it. I guess the exception is comparable to a general
>>> SQLException and will inform about things like a lost connection to
>>> the repository. The JavaDoc [1] doesn't say anything special about it.
>>>
>>> The goal of JCRM is, to provide a meta model that is based on JSR-170
>>> including a storage mechanism (an EStore implementation). Users are
>>> able to create an own domain model and refer to the meta model e.g.
>>> by changing some of their .genmodel properties.
>>> This way they should get their complete editor for their specific
>>> domain that is backed by a Java Content Repository by just clicking
>>> "generate All". At the moment it looks like it can work like that
>>> except that they would need to handle the exceptions in their
>>> generated edit plugin manually. I will have a look into the EMF code
>>> generation and how practical it is to enhance it without forking it
>>> for JCRM.
>>>
>>> >How is a user really supposed to use an API like this?
>>> He should get a dialog box saying something like "Repository
>>> connection lost. Please try to reconnect if the repository is
>>> available again."
>>>
>>> Ciao,
>>>
>>> Sandro
>>>
>>> [1] -
>>> http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/I tem.html#getName()
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Sandro,
>>>>
>>>> Accessors are never generated to throw an exception (there's no way
>>>> to declare that for an EStructuralFeature in Ecore) so we really
>>>> won't expect something like this. Does it really make all that much
>>>> sense that any access of the name feature can throw an arbitrary
>>>> checked exception? What happens in the generated eGet method? I
>>>> guess that's okay because the generated method in the implementation
>>>> doesn't actually thrown an exception? How is a user really supposed
>>>> to use an API like this? If it were a RuntimeException, at least
>>>> you wouldn't have to check it. That would seem more reasonable...
>>>>
>>>>
>>>> Sandro Böhme wrote:
>>>>> Hello again,
>>>>>
>>>>> just to make it more explicit and easier to reproduce here is an
>>>>> annotated java source that matches the scenario:
>>>>>
>>>>> ============================================================ ==
>>>>> package mypackage;
>>>>>
>>>>> import org.eclipse.emf.ecore.EObject;
>>>>> /**
>>>>> * @model
>>>>> */
>>>>> public interface MyClass extends EObject {
>>>>> /**
>>>>> * @model
>>>>> */
>>>>> public String getName() throws Exception;
>>>>> }
>>>>> ============================================================ ==
>>>>> If one generates the .genmodel from that annotated java source,
>>>>> generates the model and finally the edit plugin one see the compile
>>>>> error. Is that case designed to be handled by the code generation
>>>>> framework?
>>>>> Thanks in advance for any help.
>>>>>
>>>>> Bye,
>>>>>
>>>>> Sandro
>>>>>
>>>>> Sandro Böhme schrieb:
>>>>>> Hello,
>>>>>>
>>>>>> I have basically an EClass that has a name attribute. This
>>>>>> attribute throws an Exception. If I generate the Edit plugin from
>>>>>> this model it does not handle the Exception. E.g. catching it or
>>>>>> throwing it to the UI. The problem is located in the
>>>>>> getText(Object object) method of the provider class. By default it
>>>>>> uses the name attribute to display the label of the model-item.
>>>>>>
>>>>>> Is there any possibility to configure the model that the Edit
>>>>>> plugin gets generated in a way that handles the Exception? Or do I
>>>>>> need to handle the Exception after the generation manually?
>>>>>> Any hint is much appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Sandro
>>
>>
>
>
|
|
|
| Re: Exception is not handled by the provider classes of the generated Edit plugin [message #417598 is a reply to message #417593] |
Mon, 17 March 2008 01:27 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Sandro,
Comments below.
Sandro Böhme wrote:
> Hi Ed,
>
>> Still, I can't imagine writing an application where every
>> method I use for even the most basic of fine grained data access
>> requires a try-catch block...
> the methods on the javax.jcr.Node for example compare to the methods on
> the java.sql.ResultSet [1] in this regard. In the first case all data
> access throws at least a RepositoryException and in SQL
> java.sql.SQLException is thrown for methods accessing data.
>
> But of course in JCRM try-catch should not be needed for simple model
> traversal or something like that. This is why I changed my wrapper
> class that all domain classes extend from to not expose the
> javax.jcr.Node interface anymore. Now the interfaces do not contain
> checked exceptions and I throw a RuntimeException in getName() that
> contains the checked exception in the "cause" of the exception. This
> does cleanly solve the issue while framework users are still able to
> receive the exception.
>
> Do you think it makes sense for EMF to display the RuntimeExceptions
> thrown in the domain model in a dialog box of the generated editor?
> Maybe one could catch them at some general content provider level.
I suppose that would be reasonable. Probably right now they are
logged... I'm not sure there's a way to make the logged exceptions show...
>
>> Perhaps these aren't really like
>> attributes (EStructuralFeatures) but more like EOperations with
>> exceptions...
> A javax.jcr.Node instance can have child nodes and properties.
> The child nodes are contained in the parent. The properties can be of
> the following types:
> o String, InputStream, Long, Double, Date, Boolean
> o Name (consists of a namespace and a local name like an XML element)
> o Path (is an XPath to a node, it does not ensure referential integrity)
> o Reference (contains a reference to an node, it does ensures
> referential integrity)
> I think this is more like EStructuralFeatures than like EOperations and
> writing this makes me wanna implement it in Ecore ;-).
> What do you think?
>
> [1] - http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSet.h tml
All these look like things that take arguments. They seem similar to
SDO's DataObject API so a similar approach might work for them...
>
> Best regards,
>
> Sandro
>
> Ed Merks schrieb:
>> Sandro,
>>
>> It seems to me to be an extremely invasive thing that *all *data
>> access must explicitly handle exceptions. What about access to items
>> in a list? It would seem far better for it to be a runtime
>> exception that can be checked optionally or allowed to percolate to
>> higher levels. Of course I don't understand the whole context, so
>> maybe it's an ignorant comment. Still, I can't imagine writing an
>> application where every method I use for even the most basic of fine
>> grained data access requires a try-catch block... Perhaps these
>> aren't really like attributes (EStructuralFeatures) but more like
>> EOperations with exceptions...
>>
>>
>> Sandro Böhme wrote:
>>> Hi Ed,
>>>
>>> > exception? What happens in the generated eGet method? I guess
>>> that's
>>> > okay because the generated method in the implementation
>>> > doesn't actually thrown an exception?
>>> exactly - that's the case.
>>>
>>> The actual case is, that the "getName() throws
>>> javax.jcr.RepositoryException" method comes from the interface of
>>> the JSR-170 (Java Content Repository) specification so I cannot do
>>> something about it. I guess the exception is comparable to a general
>>> SQLException and will inform about things like a lost connection to
>>> the repository. The JavaDoc [1] doesn't say anything special about it.
>>>
>>> The goal of JCRM is, to provide a meta model that is based on
>>> JSR-170 including a storage mechanism (an EStore implementation).
>>> Users are able to create an own domain model and refer to the meta
>>> model e.g. by changing some of their .genmodel properties.
>>> This way they should get their complete editor for their specific
>>> domain that is backed by a Java Content Repository by just clicking
>>> "generate All". At the moment it looks like it can work like that
>>> except that they would need to handle the exceptions in their
>>> generated edit plugin manually. I will have a look into the EMF code
>>> generation and how practical it is to enhance it without forking it
>>> for JCRM.
>>>
>>> >How is a user really supposed to use an API like this?
>>> He should get a dialog box saying something like "Repository
>>> connection lost. Please try to reconnect if the repository is
>>> available again."
>>>
>>> Ciao,
>>>
>>> Sandro
>>>
>>> [1] -
>>> http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/I tem.html#getName()
>>>
>>>
>>>
>>> Ed Merks schrieb:
>>>> Sandro,
>>>>
>>>> Accessors are never generated to throw an exception (there's no way
>>>> to declare that for an EStructuralFeature in Ecore) so we really
>>>> won't expect something like this. Does it really make all that
>>>> much sense that any access of the name feature can throw an
>>>> arbitrary checked exception? What happens in the generated eGet
>>>> method? I guess that's okay because the generated method in the
>>>> implementation doesn't actually thrown an exception? How is a user
>>>> really supposed to use an API like this? If it were a
>>>> RuntimeException, at least you wouldn't have to check it. That
>>>> would seem more reasonable...
>>>>
>>>>
>>>> Sandro Böhme wrote:
>>>>> Hello again,
>>>>>
>>>>> just to make it more explicit and easier to reproduce here is an
>>>>> annotated java source that matches the scenario:
>>>>>
>>>>> ============================================================ ==
>>>>> package mypackage;
>>>>>
>>>>> import org.eclipse.emf.ecore.EObject;
>>>>> /**
>>>>> * @model
>>>>> */
>>>>> public interface MyClass extends EObject {
>>>>> /**
>>>>> * @model
>>>>> */
>>>>> public String getName() throws Exception;
>>>>> }
>>>>> ============================================================ ==
>>>>> If one generates the .genmodel from that annotated java source,
>>>>> generates the model and finally the edit plugin one see the
>>>>> compile error. Is that case designed to be handled by the code
>>>>> generation framework?
>>>>> Thanks in advance for any help.
>>>>>
>>>>> Bye,
>>>>>
>>>>> Sandro
>>>>>
>>>>> Sandro Böhme schrieb:
>>>>>> Hello,
>>>>>>
>>>>>> I have basically an EClass that has a name attribute. This
>>>>>> attribute throws an Exception. If I generate the Edit plugin from
>>>>>> this model it does not handle the Exception. E.g. catching it or
>>>>>> throwing it to the UI. The problem is located in the
>>>>>> getText(Object object) method of the provider class. By default
>>>>>> it uses the name attribute to display the label of the model-item.
>>>>>>
>>>>>> Is there any possibility to configure the model that the Edit
>>>>>> plugin gets generated in a way that handles the Exception? Or do
>>>>>> I need to handle the Exception after the generation manually?
>>>>>> Any hint is much appreciated.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Sandro
>>
>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 22:33:43 GMT 2024
Powered by FUDForum. Page generated in 0.04230 seconds |
] 
Search
Help
Register
Login
Home
