1Exercise a method containing a `try' statement with several 2instructions with a `finally' clause but without any `catch' block, 3enclosed in a loop. 4 5When dx processes an integer division (or modulo) enclosing a `try' 6block and whose result is assigned to a local value, it is smart 7enough not to emit a `div-int' (or `rem-int') instruction when the 8divisor is non-null, as it wouldn't be used. However, dx is not 9that clever regarding exception handling: if the divisor is known to 10be non-null at compile-time (as is the case in this test), it will 11still emit a block with the exception catching and rethrowing 12mechanism, even if it is not used. 13 14This used to be a problem for a `try' block followed by a `finally' 15clause but with no `catch' block: in that case, the generated Dex code 16item would list zero catch block for this method (see 17art::CodeItem::tries_size_) and the optimizing compiler would have no 18clue that it contains a `try' statement, which it cannot optimize 19(yet). With no hint that this method might contain one (or several) 20special block(s) related to `catch'-less `try' statement(s), the 21optimizing compiler considered this (these) as dead block(s) and 22improperly tried to remove its (their) instructions, sometimes 23removing instructions used by others instructions, thus triggering 24assertions. The optimizing compiler was thus adjusted to remove these 25instructions in a proper fashion, by removing them as users first, and 26then by suppressing them for good. 27