The probability that you will accidentally mask AssertionError somewehre else in your code is much lower than the probability to accidentally mask RuntimeException.

I disagree with this claim. It depends on the environment, on the expertise of the users, and on the consequences of the various kinds of failure.

Video games is an application area I know fairly well. Here it’s vital to “fail fast” in development, when you have a chance to analyze and fix the problem. But on a console, failing fast is almost always wrong. There’s nothing the player can do about it, and nothing much you could do about it even if the player could report the bug to you; the game completed its manufacturing run long ago and you have no way of issuing a patch.

There’s almost always some way to handle an error that allows the game to continue running, or which minimizes the consequence of the error for the player. Even when there’s nothing you can do, often the game will be able to limp along despite the error. For example, in development we perform fencepost checking on all allocated memory blocks to detect buffer overruns and other memory corruption errors. But in release we don’t bother: there’s a chance that the undetected memory corruption is harmless, or merely overwrites part of a texture, resulting in graphic corruption but leaving the game still playable. And the worst that can happen is that the game crashes, which from the player’s point of view is no worse than the game throwing an exception.

The decision might be different for PC games because there you do have the possibility of issuing a patch. But that’s exactly my point: the environment matters.

I may eventually move to a map structure if it seems necessary. The problem is the map is too large to embed in source code, close to 100,000 entries. Perhaps some other data structure may prove useful. If this isn’t fast enough, I’ll investigate. However the biggest concern right now is not code speed but code size. the current method skirts close to the boundaries of the maximum method size in Java, and not all tools can handle. This revision should reduce the method down to maybe a fifth of its current size and probaboly be faster to boot.

There are lots of alternatives in Java, but they all run more slowly.

I work in video games, where there are similar issues. If you get a bad result from a subsystem, you have to do something: it’s not acceptable just to crash or report a fatal error. Maybe the networking subsystem has gone wrong, but if the game continues to run then at least the player may be able to save their game.

During testing, of course, it’s vital to be informed about unanticipated events, so the general technique we use looks like this:

if (unanticipated_event) {
if (testing) {
assert(false, “Unexpected result: … details here …”);
}
// Do something sensible,
// e.g. drop into the handling code for a different error,
// or as a last resort just carry on as if nothing happened.
}

In the specific case of your XOM Unicode program, the highly repetitive structure looks really unfortunate. Is there nothing in Java to help you with this? In a language like Python or JavaScript with built-in hash tables you’d write something like:

data = {
0×0: “NOT_REORDERED”,
0×1: “OVERLAY”,
0×7: “NUKTA”,
0×8: “KANA_VOICING”,
0×9: “VIRAMA”,
# etc …
}
try:
return result + data[i]
except KeyError:
# Handle the unexpected key here.

And in C or C++ you could use the relational macros technique.

Sometimes users will have code with a ‘catch (Exception e)’ and an empty block, effectively ignoring all Exceptions, of which RuntimeException is a subclass. Throwing Error avoids this, although it can still get caught with ‘catch (Throwable t)’, so no amount of fool-proofing can avoid a truly dedicated fool.

And I also suggest prefixing the toHexString() value with “0x”, to avoid propagating the ambiguity you fell prey to.