You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Marco Ferrante (JIRA)" <ji...@apache.org> on 2008/12/30 17:30:44 UTC
[jira] Created: (EXEC-32) PumpStreamHandler handles null streams
inconsistently
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
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (EXEC-32) PumpStreamHandler handles null streams
inconsistently
Posted by "Marco Ferrante (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/EXEC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marco Ferrante updated EXEC-32:
-------------------------------
Comment: was deleted
> 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.
[jira] Updated: (EXEC-32) PumpStreamHandler handles null streams
inconsistently
Posted by "Marco Ferrante (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/EXEC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marco Ferrante updated EXEC-32:
-------------------------------
Attachment: DefaultExecutorTest.patch
PumpStreamHandler.patch
With the patch attached, redirection of _output_ or _error_ streams to {{null}} will discharge feedback silently, without errors.
Three new test cases are included.
> 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
> Attachments: DefaultExecutorTest.patch, PumpStreamHandler.patch
>
>
> 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.
[jira] Updated: (EXEC-32) PumpStreamHandler handles null streams
inconsistently
Posted by "Marco Ferrante (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Resolved: (EXEC-32) PumpStreamHandler handles null streams
inconsistently
Posted by "Siegfried Goeschl (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/EXEC-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Siegfried Goeschl resolved EXEC-32.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.0
Applied that patch (my code was already a little bit out-of-sync)
> 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
> Fix For: 1.0
>
> Attachments: DefaultExecutorTest.patch, PumpStreamHandler.patch
>
>
> 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.