One, foreword

This article, the second in a series exploring the art of Android SDK development, looks at exceptions in Java/Android and how to think about merging design with the characteristics of exceptions in SDK development. Note that this paper does not involve the detailed introduction of exceptions and the sequence of code execution after the occurrence of exceptions, but based on the basic characteristics of exceptions and responsibility boundaries, combined with the actual situation of business development, trying to discuss the choice of throwing exceptions and error codes.

Series of articles:

Android SDK Development Art Exploration (1) Introduction and Design

(2) Exception or ErrorCode

Android SDK development art exploration (iii) initialization

Android SDK development art exploration (4) personalized configuration

Android SDK development art exploration (5) security and verification

Android SDK development art exploration (6) compression and optimization

Android SDK development art exploration (vii) Dependency principles and packaging methods

Second, the concept of exceptions

First, let’s recognize exceptions:

An exception is an unexpected event that occurs during program execution and interrupts the flow of normal execution of the program (current method or scope).

  • Checked Exceptions, like the most common onesIOExceptionThis type of exception is the type that needs to be handled explicitly at the call, either by a try catch or by a throw;
  • Unchecked Exception is all classes that inherit from Error (including itself) or RuntimeException (including itself), such as the common onesNullPointerExceptionThis is the category. These exceptions are not forced to be handled explicitly at the call, but can also be handled by a try catch;
  • Throwable isExceptionandErrorThe parent class.

2.1. How APP developers view anomalies

In APP development, it seems that we are always passively writing exception code based on compiler prompts, just to let the compiler pass. Why is the compiler messing with us? Because these prompts are all due to the Checked type exception thrown for the operation, they need to be handled explicitly manually.

In Java development, NullPointerException, or NPE for short to some, is an exception that every developer is familiar with and hated.

Java Programmer: Either debugging NPE or on the way to debugging NPE.

2.2 SDK developers’ perspective on exceptions

In SDK development, in addition to dealing with those exceptions in APP development, we also need to fully consider the impact of those logic interrupted by exceptions on the overall interaction process.

The logic of SDK itself is inseparable from APP. If the internal process of SDK is interrupted due to an abnormality within SDK, and APP is not informed of this, it is obviously unacceptable. Therefore, exceptions that occur within the SDK must be handled carefully. The principle is that exceptions should not be digested internally, but should be thrown outwards, in the form of the same exception or a custom return code.

2.3 Exception or ErrorCode, this is a problem

In the logical design of the SDK, the developer can be informed either by an exception or by a return code, so how to choose? Let’s explore this with two examples

  • ** Scenario 1: ** In the SDK entry parameter, the APP needs to pass in the mobile phone number and verify the validity of the parameter
  • Scenario 2: Inside the SDK, obtain the APP ID and perform whitelist verification

In these two scenarios, it is necessary to process and give feedback in the CALL process of SDK, and the feedback can be through the return code, or directly throw exceptions (built-in exceptions or custom exceptions).

In my opinion, in our actual SDK development, we should classify related errors to decide whether to use exception interaction or return code interaction

Custom exceptions are a heavier form of notification because exceptions mean interruptions. The return code is a relatively “light” notification method, and it is also the least likely to attract attention from developers.

Common SDK developers do not have a clear return code comparison table, and common APP developers do not fully handle all return cases. Therefore, for irreversible errors, it is recommended to use the exception handling mechanism to directly interrupt the program execution process to completely expose the problem and avoid more unexpected errors.

Specifically summarized as:

Where business-related logic involves the user (note, non-developer, same below) being able to retry, a return code should be used to inform the developer for subsequent processing. For example, if users input information that does not conform to the rules of mobile phone numbers, they can return the corresponding return code through our custom check logic, which can be processed by developers integrating SDK.

In the case of non-business logic that users cannot handle by themselves, you can throw custom exceptions. For example, the SDK develops validation for the package name of the APP, which is a validation logic for the developer, so you might as well throw a custom exception and crash the APP, letting the developer find the problem from the error stack. This scenario is, perhaps, an example of Unchecked Exception being used.

Exception or ErrorCode, I think you have a perceptual understanding of this issue. Readers who are patient with this point are also welcome to express their opinions.

Three, endnotes

This article reviews the concept of exceptions and discusses how to use exceptions in SDK development. To sum up:

  1. Retried logical exceptions such as invalid parameters caused by users should be exchanged by return codes.
  2. For proprietary exceptions that cannot be retried due to non-compliance by the developer, exit the program by throwing the exception directly because this type of error should not be exposed to the user and is not necessary to continue the business process;

Next, we will continue to discuss the design of initialization in SDK development, including several ways of initialization, the impact of initialization on APP startup, and by the way, we will introduce the implementation of Java dual inheritance that we learned by mistake during SDK development.

Finally, if this document is helpful or inspiring to your development, like/follow/share three lines is the best incentive for the author to continue to create, thanks for your support!

Refer to the article

  • Exceptions in Java
  • Handle your Java exceptions gracefully
  • Tutorial exceptions definition

Copyright Notice:

This article first appeared in my column AndDev Android development has been authorized to hongyang public account exclusive release.