Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
ego_script [2026/08/07 03:27]
hermann old revision restored (2026/07/30 19:17)
ego_script [2026/08/07 03:51] (current)
hermann
Line 476: Line 476:
 ==== Error-handling pattern ==== ==== Error-handling pattern ====
  
-The error-handling containers are most useful when combined ​with a [[#​carrying_and_selecting_values_across_iterations|junction]] ​outside ​the block. The sentinel and the risky functor ​inside the container ​have no data dependency on each other, ​so they execute independently. The pattern works as follows:+The error-handling containers are most useful when paired ​with something outside the block that reacts to the outcome — a [[#​carrying_and_selecting_values_across_iterations|junction]] ​when the goal is a fallback value, [[If Then]]/[[If Not Then]] when the branches need to do different things (see below). The functors ​inside the container ​are typically independent of each other, ​with no data dependency forcing a particular order; what changes between the two containers is what happens to their results if one of them fails partway through. The pattern works as follows:
  
-  - If the risky functor raises an error, [[Skip All On Error]] captures it and discards **all** results produced by functors inside the container — including the sentinel, ​even though it completed successfully on its own. +  - If any functor ​inside ​raises an error, [[Skip All On Error]] captures it and discards **all** results produced by functors inside the container — even results that had already ​completed successfully on their own. 
-  - Outside the container, a **junction** tests whether ​anything ​propagated out. If the sentinel ​was discarded (error case), ​the container produced nothing and the junction falls back to its default ​value. If no error occurred, the sentinel ​propagates normally and the junction forwards it.+  - Outside the container, a **junction** tests whether ​a given value propagated out. If it was discarded (the error case), the junction falls back to its default. If no error occurred, the value propagates normally and the junction forwards it.
  
-This example ​tests whether ​a map file can be loaded successfully:+This example ​loads categorical ​map together with a lookup table of transition weights that only makes sense paired with that specific map; if either ​file is missing, both should fall back to a matched pair of defaults, rather than risking a real map paired with mismatched default weights, or the reverse:
  
 <​code>​ <​code>​
 _ := SkipAllOnError .yes {{ _ := SkipAllOnError .yes {{
-    // The sentinel has no dependency on LoadMap — both execute independently. +    // loadedMap and loadedWeights need to succeed together or not at all -- 
-    // If LoadMap raises an error, SkipAllOnError discards ​all results inside+    // if either file is missing, SkipAllOnError discards ​botheven 
-    // including this sentinel+    // whichever one loaded successfully,​ so the junctions below always 
-    ​booleanValue0 ​:= BooleanValue ​.yes;+    // fall back to a matched, consistent pair of defaults
 +    ​loadedMap ​:= LoadMap mapFilename;​ 
 +    loadedWeights := LoadLookupTable weightsFilename;​ 
 +}}; 
 + 
 +// If either load failed, both loadedMap and loadedWeights were discarded,​ 
 +// and both junctions fall back to their defaultsIf both succeeded, each 
 +// junction forwards the real value. 
 +mapOrDefault := MapJunction loadedMap defaultMap; 
 +weightsOrDefault := LookupTableJunction loadedWeights defaultWeights;​ 
 +</​code>​ 
 + 
 +When only a pass/fail signal is needed — not an actual fallback value — a junction is unnecessary:​ [[Skip All On Error]] already reports success or failure directly through its own ''​executionCompletedSucessfully''​ output, with no sentinel or junction required: 
 + 
 +<​code>​ 
 +result := SkipAllOnError .yes {{
     _ := LoadMap inputMapFilename;​     _ := LoadMap inputMapFilename;​
 }}; }};
-// If the sentinel was discarded (error), the junction falls back to false (0). 
-// If no error occurred, the sentinel propagates and the junction returns true. 
-result := ValueJunction booleanValue0 0; 
 </​code>​ </​code>​
  
-[[Skip On Error]] behaves differently:​ instead of discarding all results, it preserves the outputs of any functors that had already completed when the error was raised. ​In the pattern ​above this means the sentinel ​would always propagate ​— making ​[[Skip On Error]] ​suitable for cases where partial results ​from a failed block are still useful, not for simple success/failure test.+''​result''​ is that boolean directly. The paired-fallback pattern above earns its extra complexity only when a real value, not just a flag, needs a fallback on failure. 
 + 
 +[[Skip On Error]] behaves differently:​ instead of discarding all results, it preserves the outputs of any functors that had already completed when the error was raised. ​Substituting it into the paired-loading example ​above would be a mistake: since ''​loadedMap''​ and ''​loadedWeights''​ have no data dependency on each other — see [[#​functors_variables_and_binding|Functors,​ variables, and binding]] for that execution-order rule stated generally — nothing guarantees which of the two, if either, has already completed by the time the other'​s error is raised. The outcome ​would be a race: a real map could end up paired with default weights, or the reverse, unpredictably from run to run. [[Skip All On Error]] sidesteps that race entirely ​— it discards both regardless of which one failed or how far the other had gotten — which is exactly what "​succeed together or not at all" requires. ​[[Skip On Error]] ​instead earns its place when partial results are genuinely fine to keep on their own — see below. 
 + 
 +Whatever [[Skip On Error]] preserves is what each branch has to work with. If the branches only need to pick between two values — the case in the [[manipulating_tables_and_lookup_tables#​printing_a_table_with_a_generic_format|generic printer]] above — a junction is the simplest tool. But when the branches need to carry out different logic rather than just hand a value onward[[If Then]]/[[If Not Then]] can test [[Skip On Error]]'​s own ''​executionCompletedSucessfully''​ output directly — no separate sentinel needed, unlike the paired-loading [[Skip All On Error]] pattern above. This example attempts to load an optional mask map; if it loads, the matching branch has the mask itself to work with, and if it's missing or fails to load, the other branch proceeds without one: 
 + 
 +<​code>​ 
 +maskLoaded := SkipOnError .yes {{ 
 +    mask := LoadMap maskFilename;​ 
 +}}; 
 + 
 +// maskLoaded is SkipOnError'​s own boolean output; mask itself -- preserved 
 +// on success -- is what the matching branch below actually needs. 
 +_ := IfThen maskLoaded {{ 
 +    Print "Mask loaded; masking enabled"​ .none {{ }}; 
 +}}; 
 + 
 +_ := IfNotThen maskLoaded {{ 
 +    Print "​Mask ​not found; continuing without one" .none {{ }}; 
 +}}; 
 +</​code>​ 
 + 
 +Contrast this with picking ​value out of two mutually exclusive attempts, as in [[manipulating_tables_and_lookup_tables#​printing_a_table_with_a_generic_format|Manipulating Tables and Lookup Tables]]: when both branches would just hand the same kind of value onward, a junction is the simpler tool; ''​IfThen''​/''​IfNotThen''​ earns its place when the branches need to do something different.
  
 ---- ----
Line 1080: Line 1114:
 | **Use abbreviated syntax for Calculate family functors** | Whether the ''​Calculate''​ family is written using the shorthand symbol (''#'',​ ''##'',​ ''​%'',​ etc.) or the full functor name. See the [[#​calculator_functor_shorthand|Calculator functor shorthand]] section for details. | | **Use abbreviated syntax for Calculate family functors** | Whether the ''​Calculate''​ family is written using the shorthand symbol (''#'',​ ''##'',​ ''​%'',​ etc.) or the full functor name. See the [[#​calculator_functor_shorthand|Calculator functor shorthand]] section for details. |
 | **Preferred number of columns before wrapping comments** | The line width at which the generator wraps long comment text. | | **Preferred number of columns before wrapping comments** | The line width at which the generator wraps long comment text. |
 +