On Fri, 27 Oct 2023 08:52:42 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> OOME is pretty much understood to be possible anywhere, given it is a >> VirtualMachineError. We often do not document it explicitly. The risk with >> documenting it is that it gives the impression that other methods, which >> don't document it, can never throw it. A rough grep for `@throws >> OutOfMemoryError` reveals only 15 classes in java.base that explicitly >> document this. > > That said, I also agree with @dholmes-ora - e.g. I'm not sure how much OOME > is important to document here, since it reflects an internal state of the > JVM, rather than something the client can do something about. > > E.g. if you create an allocator with `SegmentAllocator::slicingAllocator`, at > some point you are going to run out of space in the underlying segment, so it > makes sense to report failures (and to document why that happens). But in > this case the documentation is going to be very vague, and I don't think it > provides a lot of value. Ok. I figured it was similar to Unsafe::allocateMemory, which also documents to OOME. But then again, the user is not directly interested in memory in this case. I"ll remove these `@throws` tags then ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16311#discussion_r1374303739
