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 cc18d4f40..6199ed408 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();