|
9 | 9 | import static org.hamcrest.CoreMatchers.is; |
10 | 10 | import static org.hamcrest.CoreMatchers.not; |
11 | 11 | import static org.hamcrest.CoreMatchers.nullValue; |
| 12 | +import static org.junit.Assert.assertNotNull; |
12 | 13 | import static org.junit.Assert.assertThat; |
13 | 14 | import static org.junit.Assert.assertTrue; |
14 | 15 | import static org.junit.Assert.fail; |
@@ -110,16 +111,25 @@ public void throwsIfCountNegative() throws Exception { |
110 | 111 | } |
111 | 112 | } |
112 | 113 |
|
| 114 | + /** |
| 115 | + * I think this case should just throw an exception, as trying to read zero |
| 116 | + * bytes doesn't make much sense to me. But it seems we need to accept a |
| 117 | + * "read of zero bytes" as a legal case. So jssc will respond with an empty |
| 118 | + * array, exactly as caller did request. |
| 119 | + * See also "https://github.com/java-native/jssc/issues/192". |
| 120 | + * |
| 121 | + * Update: According to |
| 122 | + * https://github.com/java-native/jssc/issues/192#issuecomment-2960137775 |
| 123 | + * there seems to exist some other issue related to events, which occasionly |
| 124 | + * provocates zero-length reads. So as long this other issue exists, jssc |
| 125 | + * probably should handle zero-length reads, as it seems to cause them |
| 126 | + * itself. */ |
113 | 127 | @Test |
114 | | - public void throwsIfCountZero() throws Exception { |
| 128 | + public void returnsAnEmptyArrayIfCountIsZero() throws Exception { |
115 | 129 | SerialNativeInterface testTarget = new SerialNativeInterface(); |
116 | | - byte[] ret; |
117 | | - try{ |
118 | | - ret = testTarget.readBytes(0, 0); |
119 | | - fail("Where's the exception?"); |
120 | | - }catch( IllegalArgumentException ex ){ |
121 | | - assertTrue(ex.getMessage().contains("0")); |
122 | | - } |
| 130 | + byte[] ret = testTarget.readBytes(0, 0); |
| 131 | + assertNotNull(ret); |
| 132 | + assertTrue(ret.length == 0); |
123 | 133 | } |
124 | 134 |
|
125 | 135 | @Test |
|
0 commit comments