{'fraction_non_alphanumeric': 0.02040816326530612, 'fraction_numerical': 0.0, 'mean_word_length': 5.096045197740113, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Catch me if you can: permissive yet secure error handling

Program errors are a source of information leaks. Tracking these leaks is hard because error propagation breaks out of program structure. Programming languages often feature exception constructs to provide some structure to error handling: for example, the try...catch blocks in Java and Caml. Mainstream information-flow security compilers such as Jif and FlowCaml enforce rigid rules for exceptions in order to prevent leaks via public side effects of computation whose reachability depends on exceptions.
 This paper presents a general and permissive alternative to the rigid solution: the programmer is offered a choice for each type of error/exception whether to handle it or not. The security mechanism ensures that, in the former case, it is never handled and, in the latter case, it is always handled with the mainstream restrictions. This mechanism extends naturally to a language with procedures and output, where we show the soundness of the mechanism with respect to termination-insensitive noninterference.