| Changing MyEnumType.get(String) to throw an exception [message #780496] |
Wed, 18 January 2012 10:36  |
 Ben Tenne
Messages: 50
Registered: October 2009 |
Member |
|
|
Hi,
I'm looking at the feasibility of changing the generated get(String) method for generated enumeration types to throw an exception (probably IllegalArgumentException) when called with a String that doesn't match one of the literals. The existing behaviour is that the method returns null in this scenario.
Is anyone aware of any dangers of changing the behaviour in this way? i.e. If any of the inner workings of EMF rely on this (including additional components like Teneo) then they may break if I make this change. Given that these methods are type-specific, rather than being declared on a super-type/interface, they're not technically part of an API, but that doesn't mean that they're not called by EMF (i.e. by reflection). I would imagine that any such code interested in converting a String to an enum would be using Enum.valueOf(Class,String) anyway.
If I changed get(String), then you could argue that getByName(String) and get(int) should be changed too, for the sake of consistency, which obvious increases the risk further.
Please note that I'm not necessarily suggesting this change is a good idea, but it has been suggested to me that the change in behaviour would be an improvement. After all, methods in the JDK such as Integer.valueOf(String) have the same pattern and would throw an exception when the String is inappropriate. Convincing justifications for not messing with this logic are equally welcome!
Cheers,
Ben.
|
|
|
| Re: Changing MyEnumType.get(String) to throw an exception [message #780978 is a reply to message #780496] |
Wed, 18 January 2012 10:50  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ben,<br>
<br>
That specific method is called from the generated factory, but it
throws an unchecked exception anyway.<br>
<blockquote> public GenDelegationKind
createGenDelegationKindFromString(EDataType eDataType, String
initialValue)<br>
{<br>
GenDelegationKind result =
GenDelegationKind.get(initialValue);<br>
if (result == null) throw new IllegalArgumentException("The
value '" + initialValue + "' is not a valid enumerator of '" +
eDataType.getName() + "'");<br>
return result;<br>
}<br>
</blockquote>
I can't think of cases where you'd have a problem throwing
exceptions from those methods.<br>
<br>
<br>
On 18/01/2012 11:36 AM, Ben Tenne wrote:
<blockquote cite="mid:jf67c7$1ea$1@news.eclipse.org" type="cite">Hi,
<br>
<br>
I'm looking at the feasibility of changing the generated
get(String) method for generated enumeration types to throw an
exception (probably IllegalArgumentException) when called with a
String that doesn't match one of the literals. The existing
behaviour is that the method returns null in this scenario.
<br>
<br>
Is anyone aware of any dangers of changing the behaviour in this
way? i.e. If any of the inner workings of EMF rely on this
(including additional components like Teneo) then they may break
if I make this change. Given that these methods are type-specific,
rather than being declared on a super-type/interface, they're not
technically part of an API, but that doesn't mean that they're not
called by EMF (i.e. by reflection). I would imagine that any such
code interested in converting a String to an enum would be using
Enum.valueOf(Class,String) anyway.
<br>
<br>
If I changed get(String), then you could argue that
getByName(String) and get(int) should be changed too, for the sake
of consistency, which obvious increases the risk further.
<br>
<br>
Please note that I'm not necessarily suggesting this change is a
good idea, but it has been suggested to me that the change in
behaviour would be an improvement. After all, methods in the JDK
such as Integer.valueOf(String) have the same pattern and would
throw an exception when the String is inappropriate. Convincing
justifications for not messing with this logic are equally
welcome!
<br>
<br>
Cheers,
<br>
Ben.
<br>
</blockquote>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.26444 seconds
] 
Search
Help
Register
Login
Home
