Your example doesn't fit into either of those two categories. In order to have an invariant, `ids`, `locations`, and `metadatas` would be need to be members of

Your example doesn't fit into either of those two categories. In order to have an invariant, `ids`, `locations`, and `metadatas` would be need to be members of a well-encapsulated type, one which has `insert` as a method. So the first category is out since `insert` mutates the instance's members directly, without going through the instance's public API, and the second category doesn't apply since `insert` mutates its member instances, and not only non-member instances. I believe the author would agree that this function needs the "try" keyword to show that the invariants can be broken by an ill-placed throw. The proposal is to keep the "try" keyword but allow functions to explicitly opt out so that "try" is not needed on every function call which can throw. The author suggested a "throws_anywhere" keyword after the argument list. My proposal would be to add "try blocks" which have the effect of allowing an exception to be rethrown anywhere inside the block (i.e. within a "try block" you can omit the normal "try" on a function call). The pattern: try { do_something(); do_something_else(); } would be equivalent to: try do_something(); try do_something_else(); So if you wanted the effect of "throws_anywhere" you just wrap the whole body of the function in one of these blocks. But you could also wrap just part of a function, for example just the part where the invariants are maintained, and require explicit handling in the parts where invariants are temporarily broken.