From b24c0b07a35898b023b74922e630fde851b7f6e5 Mon Sep 17 00:00:00 2001
From: Philip S Doctor <diomedestydeus@gmail.com>
Date: Thu, 22 Feb 2018 16:54:35 -0600
Subject: [PATCH] When Java raises a CharacterCodingException, the catch block
rethrows this exception as a java.lang.Error. Per the docs
https://docs.oracle.com/javase/8/docs/api/java/lang/Error.html an Error is a
serious problem that applications should not attempt to catch such as
ThreadDeath. In this case, it is reasonable for a consumer to try to catch
this error as it likely indicates a problem with the underlying data. (#4630)
As Error does not inherit from Exception, a generic `catch(Exception ex)` will not catch this error.
A simple change from `Error` to `Exception` is not sufficient as an `Exception` is checked by the compiler, so in order to keep this issue unchecked, I am proposing raising a `RuntimeException` which is not checked, but is still a subclass of `Exception`.
The only possible breaking change would be if a consumer was explicitly catching `Error` already for this library.
https://github.com/google/flatbuffers/issues/4629
---
java/com/google/flatbuffers/Table.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/com/google/flatbuffers/Table.java b/java/com/google/flatbuffers/Table.java
index cc18d4f4..6199ed40 100644
--- a/java/com/google/flatbuffers/Table.java
+++ b/java/com/google/flatbuffers/Table.java
@@ -122,7 +122,7 @@ public class Table {
cr.throwException();
}
} catch (CharacterCodingException x) {
- throw new Error(x);
+ throw new RuntimeException(x);
}
return dst.flip().toString();
--
GitLab