Fault: Throw exceptions from methods that declare those exceptions
Latency: Introduce latency on method-calls
Nullify: Replace the first non-primitive argument to the method with null
The first two seem useful. The last maybe less useful depending on how you design your project. For example, I commonly disallow null to be passed as a method parameter for internal methods. External APIs will null-check, but all internal logic expects to never be passed null. Still might be useful since you can restrict the scope of it's instrumentation on a package level.
Author here - the project did originally just have fault and latency modes, and the last one came out of discussions with a colleague about other failures that might be interesting.
I'm looking for more failure modes to add, so if you can think of any more send them my way!
Unclean network disconnects. We had to dynamically change iptables to simulate that particular failure case. It's hard to repro but something that does happen in prod and something that can cause mem leaks
Pausing within a synchronized block to exaggerate slowdown sounds really interesting - and would provide a great opportunity to learn about how locking works "under the hood" :)
This looks super useful for making things super reliable e.g., your core service kind of thing. Also if you are writing sort of critical high perf libraries/utility like a resource pool, cache, transaction manager .. the latency & fault looks specially good.
Nullify looks more interesting as a general code reliability check tool specially with the @NotNull thing another commenter mentioned.
Haven't tried Byte-Monkey, but have experimented with Byteman http://byteman.jboss.org/ which I find to be quite handy in debugging the tricky to reproduce issues
