On Wed, 17 Nov 2021 13:17:37 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
> > > After having looked at this change, I think I might have fallen prey to > > > the famous "XY problem". Instead of asking on how to emulate error > > > conditions in a black-box fashion first, I asked to provide white-box > > > support for those through JavadocTester. > > > > > > I didn't see the question this way, and I thought the JBS issue was well > > stated. > > Setting aside `JavadocTester` for a moment, there were two ways to solve > > the general problem of triggering exceptions to emulate weird conditions. > > > > 1. Build back doors into the main system `JavaFileManager` ... i..e. > > `JavacFileManager` (note `Javac`), such that the code can be triggered by > > backdoor access, either reflective, or breaking abstraction or system > > properties. > > 2. Provide a new file manager to do the job. > > > > [...] > > I should've asked an even more general question before creating JDK-8276892: > How can I _trigger_ an error from specific operations on a FileManager and a > FileObject returned from that FileManager? > [...] > > If you say that a black-box approach is impossible or impractical here, I'll > be fine with the white-box approach along the lines of what this PR suggests. I don't know of a way to reliably trigger the exceptions with the current primary file manager ... i.e. `JavacFileManager` (note the `c`). You might be able to force exceptions by playing with file system permissions, but that may be problematic to do in a platform-independent way. Here's a different way of looking at it, as an instance of a more general problem. `JavaFileManager` is effectively a service-provider interface, to provide an interface between "files" and `javac`. At the time it was written, the only access to files was via `java.io.File` and there was interest in providing access to "virtual files" such as in-memory buffers, as may be found in an IDE. (`JavaFileManager` appeared in JDK 6, and so predates the NIO `Path` and `FileSystem` APIs, which appeared later, in JDK 7; if NIO had been available in JDK 6, we might not have written `JavaFileManager`). So, as a service-provider interface, methods were declared to throw exceptions that might be expected to occur on as yet unknown implementations. Thus, there is no guarantee that any specific implementation will need or be able to throw any of the declared exceptions. For the situation that motivated this issue, the desire is to test/cover the `catch` blocks, so it does not seem so important to me how the exceptions are generated ... whether by tricking the raw `JavacFileManager` into throwing exceptions, or by wrapping it and using reflective proxy code, as here. The one thing I take away is to maybe try and improve ease-of-use, perhaps with more convenience or utility methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/6404
