write unit test for Visualizer.save throwing IOException about rtree HOT 7 CLOSED

I will be glad to do it.
I think I'll try to return to the structure of this method as we had in the beginning.
It looked ugly but seemed to work for me. I'll submit a pull request soon.

from rtree.

I wonder why it didn't work for me? What OS do you use? I'm on Linux.

from rtree.

I'm on Windows 8. Do you think there's a connection? I thought it could be a Java version issue.
But then the tests shouldn't have failed. We should've seen compilation errors.

from rtree.

So the OS might explain things because ImageIO.save calls native file routines.

from rtree.

Whatever you come up with,test it locally and it works submit a PR and Travis will automatically test your PR on linux. By the way when you submit a PR do it from a branch rather than master. Tis a convention. If you can't be bothered of course we can always get cobertura to ignore the ImageIO.save.

from rtree.

I've done some research on this. On linux locking files is advisory. This means it doesn't really prevent processes to access locked files. It's like a flag. If other processes don't cooperate with a process that locked a file, and don't check the file status it's useless. We need to change the "save" file for this. Meaning, check if the file is locked, if it is - throw an exception. This exception would be caught in our test. But it's up to you to decide if you want to go that way.

from rtree.

So I guess that means that running code coverage on linux we won't get 100%
because the branch from ImageIO.save that throws an IOException will never
get traversed. Thanks for looking at it, that's educational for me. I
reckon we run with the coverage exclusion that's commited now and call it a
job well done. Thanks for all the assistance on this one.

On 12 November 2014 18:47, maxamel [email protected] wrote:

I've done some research on this. On linux locking files is advisory. This
means it doesn't really prevent processes to access locked files. It's like
a flag. If other processes don't cooperate with a process that locked a
file, and don't check the file status it's useless. We need to change the
"save" file for this. Meaning, check if the file is locked, if not - throw
an exception. This exception would be caught in our test. But it's up to
you to decide if you want to go that way.

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

from rtree.