[External] : Re: Classfile API cleanup of labelToBci from CodeModel and CodeBuilder and removal of impl.LabelResolver
Michael van Acken
michael.van.acken at gmail.com
Fri Aug 19 06:49:38 UTC 2022
Am Fr., 19. Aug. 2022 um 07:58 Uhr schrieb Adam Sotona <
adam.sotona at oracle.com>:
> From: Michael van Acken <michael.van.acken at gmail.com>
>
>
>
> I have a single use of CodeBuilder.labelToBci(): decide whether the labels
> marking
>
> the start and end of a try block refer to the same position, as a proxy
> for "enclosed
> region is empty". If this is the case, then no exceptionCatch can be
> installed and
> all exception handlers become unreachable.
>
> How can this scenario still be supported?
>
> -- mva
>
>
>
> It is not guaranteed to get the right bytecode indexes from
> CodeBuilder::labelToBci, the method is really an exposure of internal
> implementation.
>
> Frequent common cases (like for example dropping exception handler when
> try block is empty) can be solved with CodeBuilder::trying support.
>
> CodeBuilder::trying uses CodeBuilder::block and before further actions
> asks CodeBuilder.BlockCodeBuilder::isEmpty.
>
> Now it throws an exception in case of an empty try block, however I can
> imagine it might skip all handlers instead:
>
This sounds interesting. Right now I am staying away from the higher level
entry points,
because of their WIP implementation -- as I found out when I tried to use
ifThenElse().
`trying` doesn't seem to support finally right now.
Having access to a BlockCodeBuilder instance and its isEmpty would solve my
problem. Is this something that can be done from the public API?
-- mva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220819/3fe1ed4a/attachment-0001.htm>
More information about the classfile-api-dev
mailing list