It should be throwing an exception or returning null, returning a real value is a code smell.
Sent from my iPhone > On 23 Mar 2014, at 07:55, Daniel Blaukopf <daniel.blauk...@oracle.com> wrote: > > We should be consistent about what we return, although I agree that that the > actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable. > >> On Mar 21, 2014, at 7:05 PM, Anthony Petrov <anthony.pet...@oracle.com> >> wrote: >> >> Hi David, >> >> I don't think we're making any assumptions. We feed the coordinates to a >> native API and rely on the OS to do the right thing. >> >> In other words, our assumption is that if the box lays (partially or fully) >> outside of the screen area, then the behavior is undefined. Note that the >> Screen API in Glass allows its clients to check what coordinates are valid >> (i.e. belong to a real screen). >> >> So whatever your return for pixels outside of screen bounds should be fine. >> 0x0 or 0xff000000 - both look good. However, I agree that a stricter >> specification and a check might be the best solution. >> >> -- >> best regards, >> Anthony >> >>> On 3/21/2014 8:53 PM, David Hill wrote: >>> >>> I have been working on a problem with Robot.getScreenCapture() on a 565 >>> ARM device, and while doing so, encountered a couple of questions which >>> I will bring up: >>> >>> Pixxls getScreenCapture(int x, int y, int width, int height, boolean >>> isHiDPI) >>> >>> I don't seem any real documentation that says how x,y + width,height >>> should be treated when compared to the reality of the Screen. >>> What values of x,y + width,height are reasonable ? I can picture any >>> number of scenarios with them that would result in a box that does not >>> fit within the Screen dimensions. The only implementing code I have seen >>> checks to that the width & height are >= 1. Can I/Should I handle -x >>> values ? What if the requested bounds exceed the screen ? >>> >>> If we are making assumptions that the requested box is inside the >>> screen.... then why don't we document that fact and add a check in the >>> Robot class (instead of relying on the native impls). >>> >>> If we are assuming the requested box does not have to lie within the >>> screen bounds - what should the returned values be for the pixels >>> outside the screen ? Pixel Black ? (Currently I think Lens would return >>> 0x instead of 0xff000000) >>> >>> My recommendation would be modify the JavaDoc contract to specify that >>> the x,y and x+width, y+height must be within the screen bounds, with an >>> IllegalArgumentException if out of bounds. This would be checked in >>> Robot, prior to calling the native impls. >>> >>> This code is "internal" API, so I expect the real impact would be on SQE. >
