|
From: Lieven D. (JIRA) <no...@sp...> - 2008-10-09 19:51:19
|
[ http://jira.springframework.org/browse/RCP-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lieven Doclo updated RCP-455:
-----------------------------
Fix Version/s: 1.x
> Add to the ApplicationException hierarchy for method parameter validation.
> --------------------------------------------------------------------------
>
> Key: RCP-455
> URL: http://jira.springframework.org/browse/RCP-455
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Application Framework
> Affects Versions: 0.2.1
> Environment: All
> Reporter: Kevin Stembridge
> Priority: Minor
> Fix For: 1.x
>
>
> Hi all,
> The code base makes use of Spring's Assert class for performing method parameter validation. Underneath the hood it throws either IllegalArgumentException or IllegalStateException. I'd like to suggest an alternative approach that is becoming more widely used these days and has several benefits.
> In summary, the new approach consists of creating a subclass of RuntimeException that is specific to a given application or framework and then creating several subclasses that are specific to each type of parameter validation rule we wish to enforce.
> For example:
> ApplicationException extends RuntimeException;
> InvalidArgumentException extends ApplicationException;
> NullArgumentException extends InvalidArgumentException;
> There are several advantages to this approach:
> 1. We can distinguish between exceptions being thrown from our own code and that of third parties.
> 2. The exception class can be responsible for creating a suitable error message so that the developer throwing the exception doesn't have to. This also makes the code cleaner.
> 3. Static methods can be added to the exception to simplify their use in application code.
> e.g. NullArgumentException.throwIfNull(String argumentName, Object argument);
> 4. The code is more explicit about what it does and therefore more understandable. For example, compare the following snippets. The first makes it explicit that a NullArgumentException will be thrown if the object is null. For the second, you have to read the javadoc of the Assert class to know that it will throw an IllegalArgumentException.
> NullArgumentException.throwIfNull(someObject);
> Assert.assertNotNull(someObject);
> 5. Unit testing can be more robust by ensuring that the exceptions we expect to see being thrown were actually thrown for the reason that we expected them to be thrown. Comparing the two examples below, the first can only confirm that an IllegalArgumentException was thrown but it can't confirm why, and it could possibly report a false positive.
> Example 1:
> try {
> new BogusObject(null);
> Assert.fail("Should have thrown an IllegalArgumentException");
> }
> catch (IllegalArgumentException e) {
> //do nothing, test succeeded
> }
> Example 2:
> try {
> new BogusObject(null);
> Assert.fail("Should have thrown a NullArgumentException");
> }
> catch (NullArgumentException e) {
> Assert.assertEquals("arg0", e.getArgumentName());
> }
> The RCP code base already contains an ApplicationException class but it is not widely used (only 5 refs) and it has no subclasses. I don't recommend the use of ApplicationException directly because I think that in general it is a good idea for code to be throwing as specific and informative an exception as is practicable. Spring's BeansException and DataAccessException are good examples of a rich exception hierarchy.
> Anyway, this is just a suggestion for an improvement that I think would be worth considering and I'd be interested to hear what you all think.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.springframework.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|