RFR: 8255082: HotSpot Style Guide should permit noexcept

[Kim Barrett]

On Mon, 2 Jun 2025 08:43:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> If it's easier I can bring the original change to noexcept Pull Request back from the dead and remove the merge mistakes that leaked in from my other branch, which shouldn't really be that difficult to do.

PR 15910 seems a mess; let's just leave that alone.

My inclination is to *not* treat the update as a simple sed replacement.
That's easy to author, but not so easy to (not rubberstamp) review. I'd like
to actually look at the various operators, since I've already found one recent
one that wasn't done properly. And doing that while maintaining adequate
review focus means breaking it up into more bite-sized chunks, at least for
me.

> Not sure which code is potentially marked throw() wrongly though.

new (and quickly fixed):
https://bugs.openjdk.org/browse/JDK-8358283
Inconsistent failure mode for MetaspaceObj::operator new(size_t, MemTag)

old (recently self-assigned)
https://bugs.openjdk.org/browse/JDK-8342639
Global operator new in adlc has wrong exception spec

There might have been some others noticed and probably fixed during 8305590.

And I don't know whether there are any other recent-ish additions.

> Alternatively, we could just keep throw() alongside noexcept for code that already uses it, to avoid code churn. They do mean the same thing in C++17, after all

In other words, modify this style guide change to allow (or even prefer) `throw()` rather than `noexcept`? I don't
think we want to be using both.

> (I was going to mention that there are papers for static exception specifications that propose reintroducing throw() back into C++ last I remembered, but realized that this likely doesn't mean much for us now, so this point can be ignored)

Yeah, I really don't care about something speculative for inclusion in a not even existing yet Standard.
I'm just trying to prepare us for C++17 at this point. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25574#issuecomment-2942639056