Improving Code Quality - Episode 67: Too many error representations are also a problem

queryUserModel was representing errors and exceptional cases in multiple ways: null, ApiResult.Failure, ApiResult.Success(null), the nested UserListQueryResponse.Failure, and UserListQueryResponse.Success(userModel = null). When this happens, the caller has to individually interpret the meaning of each value, and even though the actual handling is similar, the number of branches increases, which raises the complexity of the code.

The solution is to convert and unify the errors into the form the caller needs. As in the example, by changing the return type to UserModelApiResult and organizing it around a single criterion—success as Success(UserModel) and failure as Failure(UserRequestErrorType)—the caller only needs to know these two cases.

If detailed error information isn't strictly necessary, it can be simplified further into something like null. In particular, at boundaries between modules or layers, such as the data layer, internal errors from the DB or network should not be passed up as-is; they should be abstracted into a form that's easy for the upper layer to handle, or only the necessary information should be kept.