Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

CLAs look good, thanks!

Thank you for sending this.

Do you actually have a use case where you want to pass in a null listener? If not, I think it would be friendlier to developers if we instead had the constructors for these classes check whether the listener is null and throw an IllegalArgumentException if they are. You have three choices for what to do when a developer passes in a null listener:

1. Do nothing. Code will crash with a mysterious NullPointerException and the developer will think it's a Volley bug. That's not good :)
2. Guard against the NPE to avoid the crash. No crash is good, but now responses will be silently dropped. If the developer has a bug where they're accidentally passing null, they won't know about it and will need to debug more deeply. Better than crashing at random, but still not ideal.
3. Crash loudly with an appropriate error message (e.g. throw new IllegalArgumentException("ResponseListener must not be null")) at the time the error occurs. This means the developer will see the error quite clearly at the moment it occurs and will be empowered to fix it.

Since a developer who really didn't care about the response could always pass in a listener that does nothing, that feels safest to me. (And it seems very unlikely this would happen because you should really care about the responses coming back successfully, I'd think).

Thanks for response.
I thinked a lot, the third solution are indeed best. but I just consider that this can be processed like the way to process the mErrorListener field in Request class. mErrorListener field are processed like the second solution.

Thanks, I didn't think to check how mErrorListener was handled in the Request class.

I'll take this for now as an improvement and have filed #65 to consider cleaning up the two listeners together.

I find that in ClearCacheRequest class, it not need whether a mListener or a mErrorListener.

Noted at #65, thanks.