RFR (S): 8072687: Update OutputAnalyzer to work with files

[denis kononenko]

Igor,

The conversation becomes too long, so I snipped the part where we have 
no disagreement.

>>
>>> 3. since you expect FileNotFoundException, shouldn't you use it in
>>> catch clause?
>>
>> In such case I should have two catch clauses, one for
>> FileNotFoundException and another for IOException. For purpose of
>> simplicity I'd prefer to catch more generic exception.
> it's not a simplification, it's an incorrect test. you don't expect 
> any exceptions except FileNotFoundException, but catch IOException. so 
> I'd recommend you to have additional catch block for IOException w/ 
> rethrowing the exception as an unchecked one.

Ok, I got your point. The problem is in the test's name, I'd propose to 
rename it to testFileNotFoundException and catch the 
FileNotFoundException only. Another option is to simply remove this test 
due its complexity and small benefit.

>>
>>> 4. what if 'non-existing.file' exists? could you please check it in
>>> the very begging of test case?
>>
>> It shouldn't be possible as Jtreg ensures that the test is running in a
>> newly created and clean scratch directory.
> well, I can say the almost same about the whole test. the thing is 
> that your test relays on a particular behavior of jtreg and an 
> exception (line 93) won't contain any useful details. so it will be 
> very hard to investigate in case bugs in jtreg.

I think you dramatize the situation, many tests depends on jtreg's 
behavior, in particular, on its cleanup procedure. If it fail we will 
see a lot of errors in our tests. Moreover, you cannot guarantee that a 
file doesn't exist in a multiprocess environment. There always will be a 
slight chance of collision. My favorite approach to generate 
"non-existing" files is: new File(UUID.randomUUID().toString()). It 
could improve the test's reliability.

Thank you,
Denis.