Github user jbduncan commented on a diff in the pull request:
https://github.com/apache/commons-imaging/pull/27#discussion_r127778422
--- Diff:
src/test/java/org/apache/commons/imaging/common/bytesource/ByteSourceTest.java
---
@@ -66,6 +64,22 @@ protected File createTempFile(final byte src[]) throws
IOException {
}
final byte longArray[] = (baos.toByteArray());
- return new byte[][] { emptyArray, single, simple, zeroes,
longArray, };
+ return new byte[][]{emptyArray, single, simple, zeroes,
longArray,};
+ }
+
+ @Test
--- End diff --
@onealj @TheRealHaui If I were maintaining this code, I'd be happy with
either pattern.
`@Test(expected=NullPointerException.class)` would be a little shorter and
equivalent to the `try..catch` construct used here in this case.
However, the reason people tend to prefer `try..catch` is because in a lot
of cases it is not granular enough. Take this (admittedly contrived) example:
```java
@Test(expected=NullPointerException.class)
public void doSomething() {
String s = null;
assertTrue(s.isEmpty());
try {
somethingWhichThrowsNullPointerException():
} catch (NullPointerException e) {
assertNull(s);
}
}
```
In this case, rather than `somethingWhichThrowsNullPointerException(s1)`
throwing `NullPointerException` (which we expect), it will be `s.isEmpty()`
that throws it instead, which isn't what we intended, since it means the test
will always "pass".
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
