[
https://issues.apache.org/jira/browse/EXEC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Ferrante updated EXEC-32:
-------------------------------
Description:
Passing null arguments in {{PumpStreamHandler}} constructors produces
hard-to-understand errors.
E.g.
{code:java}
PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out,
System.err, null);
{code}
works correctly, so you can expect that _null_ is a valid argument.
Instead
{code:java}
PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out, null,
null);
{code}
raise a {{NullPointerException}} when {{Executor.execute()}} is invoked.
Note that exception is raised by the {{start()}} method of
{{PumpStreamHandler}} .
Surprisingly
{code:java}
PumpStreamHandler streamHanlder = new PumpStreamHandler(null, System.err,
null);
{code}
starts correctly, but fails with a {{NullPointerException}} when the process
exits.
In this case, the exception is raised by the {{stop()}} method of
{{PumpStreamHandler}} .
I think that the behavior should be more consistent and, if necessary, errors
must be reported earlier.
So I suggest two alternatives:
- if a null argument is passed to a constructor as stdout/stderr an exception
is raised immediately
- or, if stdout or stderr are set to null, default {{System.out}} and
{{System.err}} are used instead.
At least, the error should be reported before starting process in every case.
was:
Passing null arguments in PumpStreamHandler constructors produces
hard-to-understand errors.
E.g.
PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out,
System.err, null);
works correctly, so you can expect that null is a valid argument.
Instead
PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out, null,
null);
raise a NullPointerException when Executor.execute() is invoked.
Note that exception is raised by the start() method of PumpStreamHandler.
Surprisingly
PumpStreamHandler streamHanlder = new PumpStreamHandler(null, System.err,
null);
starts correctly, but fails with a NullPointerException when the process exits.
In this case, the exception is raised by the stop() method of PumpStreamHandler.
I think that the behavior should be more consistent and, if necessary, errors
must be reported earlier.
So I suggest two alternatives:
- if a null argument is passed to a constructor as stdout/stderr an exception
is raised immediately
- or, if stdout or stderr are set to null, default System.out and System.err
are used instead.
At least, the error should be reported before starting process in every case.
Formatting
> PumpStreamHandler handles null streams inconsistently
> ------------------------------------------------------
>
> Key: EXEC-32
> URL: https://issues.apache.org/jira/browse/EXEC-32
> Project: Commons Exec
> Issue Type: Bug
> Reporter: Marco Ferrante
> Assignee: Siegfried Goeschl
>
> Passing null arguments in {{PumpStreamHandler}} constructors produces
> hard-to-understand errors.
> E.g.
> {code:java}
> PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out,
> System.err, null);
> {code}
> works correctly, so you can expect that _null_ is a valid argument.
> Instead
> {code:java}
> PumpStreamHandler streamHanlder = new PumpStreamHandler(System.out, null,
> null);
> {code}
> raise a {{NullPointerException}} when {{Executor.execute()}} is invoked.
> Note that exception is raised by the {{start()}} method of
> {{PumpStreamHandler}} .
> Surprisingly
> {code:java}
> PumpStreamHandler streamHanlder = new PumpStreamHandler(null, System.err,
> null);
> {code}
> starts correctly, but fails with a {{NullPointerException}} when the process
> exits.
> In this case, the exception is raised by the {{stop()}} method of
> {{PumpStreamHandler}} .
> I think that the behavior should be more consistent and, if necessary, errors
> must be reported earlier.
> So I suggest two alternatives:
> - if a null argument is passed to a constructor as stdout/stderr an exception
> is raised immediately
> - or, if stdout or stderr are set to null, default {{System.out}} and
> {{System.err}} are used instead.
> At least, the error should be reported before starting process in every case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
