exception, and when it is thrown, apps should be terminated immediately. • Errors may be thrown from almost anywhere. (e.g. OutOfMemoryError) • If the app catches an Error and continues processing, the behavior of the app becomes unpredictable and can cause more serious problems.
to bugs. (e.g. NullPointerException) • It is a bad practice to ignore exceptions caused by bugs and continue processing. • When an exception is thrown due to a bug, the app should crash without catching it. This will make it easier to fi nd the bug in tests. • Ignoring exceptions caused by bugs may cause more serious problems.
was a bug in a task that sends data to the server, throwing a NullPointerException. • The task was implemented to catch all exceptions and simply retry. • This bug resulted in in fi nite repetition of data transmission and a huge increase in the app's traf fi c. • We were not aware of this bug until the user complained.
to interactions with outside of the app process are the exceptions that should be caught. For example, • IOException • Parsing error in API payload (e.g. JSONException) • Catch these exceptions in as speci fi c types as possible. • Note that in some libraries, even exceptions related to I/O operations extend RuntimeException. (e.g. retro fi t2.HttpException)
not catch ALL Throwables • Do not catch CancellationException • Refrain from catching RuntimeException • But some RuntimeException should be caught (e.g. retro fi t2.HttpException) • Catch speci fi c types of Exceptions