Fail-Fast instead of Fire-and-Forget

Fail-Fast

fail-safe, fail-fast, fire-and-forget

Fail Fast means, when something goes wrong, you must show an error as soon as possible, so that you can take an action to solve the problem.

With fire-and-forget (when you have no any response) there is nothing you can do, when something went wrong.

Here is few points to follow fail-fast behavior:

• assertions;
• meaningful exceptions;
• response for each request.

### Forget fire-and-forget messaging pattern There are only few use-cases where fire-and-forget must be used, but it is all about low-level communication. On application level it is always better to have a response. In general, if you have response, you can detect failure, which is much faster than when you're using fire-and-forget messaging pattern. There are many things that might go wrong. Server might stop processing your request due to programming error *(stupid typo on any side, or other mistake introduced later)*, as a result problem will raise somewhere else and it will be a lot harder to figure out what is wrong. For example: * front-end server might block request due to mistake in the *"allowed calls"* list; * server might reject request due to validation error *(if we add any in the future, but forget to check other client that implements protocol)*; * target service might no longer support this request *(somebody might try to use incompatible client version)*; * message might be simply dropped somewhere *(e.g. blocked by firewall)*. In this case we silently hide source issue, and create possibility for failure later. ---- ### Fail-Fast vs Fail-safe iterators > From Java API: > > “Note that the **fail-fast** behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. > **Fail-fast** iterators throw `ConcurrentModificationException` on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the **fail-fast** behavior of iterators should be used only to detect bugs.” Use *fail-safe* iterator when you are not bothered about `Collection` to be modified during iteration, as *fail-fast* iterator won't allow it by throwing `ConcurrentModificationException`. To avoid this exception if you remove elements during iteration, use iterator's `remove()` method instead of `remove()` method provided by your `Collection` classes. Just notice, that only concurrent collection classes *(e.g.`ConcurrentHashMap`, `CopyOnWriteArrayList`, `CopyOnWriteArraySet`)* support *fail-safe* behavior. ---- ### Systems Reaction Note: That *fail-fast* first of all means to immediately report about the failure or condition that is likely to lead to failure. When fault is detected there many ways how system can react, which usually depends of how critical is to halt the certain system. In anyway, if it's not possible to halt system immediately, the *fail-soft* or graceful shutdown approach will be followed. For *"always-available"* systems like e-commerce systems reaction might be to keep working with degrading performance. The systems like medical monitoring or flight control ones, would rather try to limit the danger or damage caused by the fault. Security & cryptologic systems would try not to expose permissions or security wholes first of all. ---- ## see Also * [Java API - ConcurrentModificationException](http://docs.oracle.com/javase/7/docs/api/java/util/ConcurrentModificationException.html) * [Java API - ConcurrentHashMap](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html) * [Fail Safe vs Fail Fast Iterator In Java](http://javahungry.blogspot.com/2014/04/fail-fast-iterator-vs-fail-safe-iterator-difference-with-example-in-java.html) * [Wiki - Fail Fast](https://en.wikipedia.org/wiki/Fail-fast) * [Martin Fowler - Fail Fast](http://martinfowler.com/ieeeSoftware/failFast.pdf) * [Keynote: Top JS frmeworks 2015](http://bloomlab.blogspot.com.ee/2015/03/top-javascript-frameworks-2015.html)