Hi Paul,
On 3/10/2015 11:22 AM, Paul Sandoz wrote:
Any sub-type of Process that does not override getPid will essentially result
in that USO being propagated to many ProcessHandle methods that depend on the
PID (parent, children, allChildren, info, compareTo). That effectively renders
ProcessHandle almost useless for sub-types outside of our control that that not
been updated.
For those methods, the default behavior can be specified, except for compareTo
they already have return values that allow for the fact that the information may
not be available, either due to OS restrictions (permissions) or is not
provided.
Empty lists for children, nulls returned from info, and even allowing for an
unavailable parent.
That's a separate issue.
If i get a ProcessHandle given to me, i do not know it's source, i dunno if
it's gonna barf if i operate on it.
It can be a goal to never throw UOE, to achieve that, the behaviors of
all of the methods
(of Process) would be defined to have outputs that have to be checked by
the app;
hence the reference to nulls; empty lists, etc.
In many cases already, if the OS does not provide values or the OS
permissions do not permit
it then the values returned are empty (instead of throwing exceptions).
That design can be extended to the external subclasses by specifying the
default behavior
of Process and then defining the behaviors of Processes created by
ProcessBuilder.
Roger
