Skip to content

System.err.println should not be used within an API #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
obourdon opened this issue Jun 2, 2014 · 3 comments
Open

System.err.println should not be used within an API #3

obourdon opened this issue Jun 2, 2014 · 3 comments

Comments

@obourdon
Copy link

obourdon commented Jun 2, 2014

Considering the fact that your great API is supposed to be used in a lot of different contexts like web service (Tomcat, Jetty, ...) as well as applications/other APIs it is very annoying to have calls to System.err.println which

  1. may be do not produce any output (web service)
  2. may pollute the user program/other API using GnuGetopt

In my case I have replaced all calls to System.err.println to throw new IllegalArgumentException which leaves it to the user/programmer to decide what he wants to do with the Exception

@nic-hartley
Copy link

I second this – Errors should be thrown for the user of the API to handle, not effectively swallowed

@arenn
Copy link
Owner

arenn commented Dec 6, 2015

Hello. Thanks for your comments. The reason this API prints errors is because the original design goal was 100% compatibility with the glibc version. I will evaluate an option to turn this off for a future update.

@cdrasmussen
Copy link

Good answer. Yours may turn out to be the better model
On Dec 6, 2015 4:37 PM, "arenn" [email protected] wrote:

Hello. Thanks for your comments. The reason this API prints errors is
because the original design goal was 100% compatibility with the glibc
version. I will evaluate an option to turn this off for a future update.


Reply to this email directly or view it on GitHub
#3 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants