From 232b666c7d5fb2a1944ed316429093ea376177d1 Mon Sep 17 00:00:00 2001 From: Heejin Ahn Date: Fri, 16 Jul 2021 13:10:56 -0700 Subject: [PATCH 1/2] Clarify delegate targetting function-level block This clarifies that `delegate` can target the function-level block, which means the exception is thrown to the caller. Also added a few more examples. AFAIK this is consistent with the current implementations in the toolchain, V8, and Spidermonkey. Fixes #176. --- proposals/exception-handling/Exceptions.md | 36 ++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/proposals/exception-handling/Exceptions.md b/proposals/exception-handling/Exceptions.md index ee89a25b..58119d7c 100644 --- a/proposals/exception-handling/Exceptions.md +++ b/proposals/exception-handling/Exceptions.md @@ -288,8 +288,7 @@ end If `call $foo` throws, searching for a catching block first finds `delegate`, and because it delegates exception handling to catching instructions associated with `$l1`, it will be next checked by the outer `catch` and then `catch_all` -instructions. When the specified label within a `delegate` instruction does not -correspond to a `try` instruction, it is a validation failure. +instructions. Note that the example below is a validation failure: ``` @@ -311,6 +310,39 @@ catching instructions (`catch`/`catch_all`/`delegate`) come after the same as if the `try` has catches but none of the catches are able to handle the exception. +If `delegate`'s immediate argument is the depth of block-like structures +(blocks, loops, and trys) + 1, i.e., the function-level block, it is considered +to be delegating the exception to the caller of the current function. For +example: +``` +try $l1 + try + call $foo + delegate 1 ;; delegate to the caller +catch + ... +catch_all + ... +end +``` +In case `foo` throws, `delegate 1` here delegates the exception handling to the +caller, i.e., the exception escapes the current function. + +When the specified label within a `delegate` instruction does not correspond to +a `try` instruction or the function-level, it is a validation failure: +``` +block $l0 + loop $l1 + try + call $foo + delegate $l0 ;; targets a 'block', validation failure + try + call $foo + delegate $l1 ;; targets a 'loop', validation failure + end +end +``` + ### JS API #### Stack traces From 81976cde0168ceb3c4d5b01e95b20482c329eb90 Mon Sep 17 00:00:00 2001 From: Heejin Ahn Date: Tue, 20 Jul 2021 21:49:41 -0700 Subject: [PATCH 2/2] Address comments --- proposals/exception-handling/Exceptions.md | 28 ++++++++++++---------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/proposals/exception-handling/Exceptions.md b/proposals/exception-handling/Exceptions.md index 58119d7c..476d434c 100644 --- a/proposals/exception-handling/Exceptions.md +++ b/proposals/exception-handling/Exceptions.md @@ -310,20 +310,22 @@ catching instructions (`catch`/`catch_all`/`delegate`) come after the same as if the `try` has catches but none of the catches are able to handle the exception. -If `delegate`'s immediate argument is the depth of block-like structures -(blocks, loops, and trys) + 1, i.e., the function-level block, it is considered -to be delegating the exception to the caller of the current function. For -example: +If `delegate`'s immediate argument is the depth of the outermost block + 1, i.e. +the function-level block, the function-level block is considered as a +`catch`-less `try` and it delegates the exception handling to the caller of the +current function. For example: ``` -try $l1 - try - call $foo - delegate 1 ;; delegate to the caller -catch - ... -catch_all - ... -end +(func $test + try $l1 + try + call $foo + delegate 1 ;; delegate to the caller + catch + ... + catch_all + ... + end +) ``` In case `foo` throws, `delegate 1` here delegates the exception handling to the caller, i.e., the exception escapes the current function.