When creating a client API, I try to avoid taking sides in these kinds of debates. So I ask myself: How is the client supposed to behave, and how do I best communicate to the client's users? For example, a thin wrapper around HTTP calls should probably only throw exceptions to communicate a failure to make the HTTP call, but an API that hides its HTTP connections as implementation details may encapsulate 3/400-class errors in "it's the caller's fault" exceptions and 500-class errors in "it's the service/library's fault" exceptions. This is especially important if the client language uses exceptions to guide developers in their use of an API.
I generally prefer to let the conventions of the language and of the community of its users guide me. Both Java and C# contain rich resources for expressing ways things can go wrong. I generally use those resources unless I see a powerful reason to not do so.
But I see no hard rules here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When creating a client API, I try to avoid taking sides in these kinds of debates. So I ask myself: How is the client supposed to behave, and how do I best communicate to the client's users? For example, a thin wrapper around HTTP calls should probably only throw exceptions to communicate a failure to make the HTTP call, but an API that hides its HTTP connections as implementation details may encapsulate 3/400-class errors in "it's the caller's fault" exceptions and 500-class errors in "it's the service/library's fault" exceptions. This is especially important if the client language uses exceptions to guide developers in their use of an API.
I generally prefer to let the conventions of the language and of the community of its users guide me. Both Java and C# contain rich resources for expressing ways things can go wrong. I generally use those resources unless I see a powerful reason to not do so.
But I see no hard rules here.