This is an automated email from the ASF dual-hosted git repository.
github-bot pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/daffodil-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new fc38a6c Publishing from 64abbf0df41a006a7a19d7daad29749b0a7dd6b5
fc38a6c is described below
commit fc38a6c0ac407b77f77b222f9270c53509055f5b
Author: John Interrante <[email protected]>
AuthorDate: Fri Apr 16 14:57:03 2021 +0000
Publishing from 64abbf0df41a006a7a19d7daad29749b0a7dd6b5
---
content/dev/design-notes/runtime2-todos/index.html | 81 ++++++++++++++++------
1 file changed, 59 insertions(+), 22 deletions(-)
diff --git a/content/dev/design-notes/runtime2-todos/index.html
b/content/dev/design-notes/runtime2-todos/index.html
index 184f6be..362c979 100644
--- a/content/dev/design-notes/runtime2-todos/index.html
+++ b/content/dev/design-notes/runtime2-todos/index.html
@@ -113,34 +113,72 @@ in order to avoid duplication.</p>
</div>
</div>
<div class="sect2">
-<h3 id="error-struct-instead-of-error-message">Error struct instead of error
message</h3>
+<h3 id="reporting-errors-using-structs-not-strings">Reporting errors using
structs, not strings</h3>
<div class="paragraph">
-<p>This change is almost complete.
-We have replaced error message strings
+<p>We have replaced error message strings
with error structs everywhere now.
-However, we should support passing
-a schema location and/or data position
-through the error struct as well as
-an error code, an integer, and a string.
-We may need to store schema locations
-(filenames and line numbers) in ERD objects
-and pass an ERD in the error struct.</p>
+However, we may need to expand the error struct
+to include a pointer (pstate/ustate for data position)
+and another pointer (ERD or static context object
+for schema filename/line number).</p>
+</div>
+<div class="paragraph">
+<p>We also may want to implement error logging variants
+that both do and don’t humanize the errors,
+e.g., a hardware/FPGA-type implementation might just output numbers
+and an external tool might have to "humanize" these numbers
+using knowledge of the schema and runtime data objects,
+like an offline log processor does.</p>
</div>
</div>
<div class="sect2">
-<h3 id="different-types-of-errors">Different types of errors</h3>
+<h3 id="recovering-after-errors">Recovering after errors</h3>
<div class="paragraph">
-<p>When runtime2 grows larger,
-we may need to distinguish & handle
-more types of errors.
-Right now we handle only
-fatal errors and validation errors.
-Fatal errors stop the program immediately.
+<p>As we continue to build out runtime2,
+we may need to distinguish more types of errors
+and allow backtracking and retrying.
+Right now we handle only parse/unparse and
+validation errors in limited ways.
+Parse/unparse errors abort the parsing/unparsing
+and return to the caller immediately
+without resetting the stream’s position.
Validation errors are collected in an array
and printed after parsing or unparsing.
-Later we may need to handle
-parser/unparser warnings and errors
-and allow backtracking after these errors.</p>
+The only places where there are calls to stop the program
+are in daffodil_main.c (top-level error handling)
+and stack.c (empty, overflow, underflow errors which should never happen).</p>
+</div>
+<div class="paragraph">
+<p>Most of the parse functions set pstate→error
+only if they couldn’t read data into their buffer
+due to an I/O error or EOF,
+which doesn’t seem recoverable to me.
+Likewise, the unparse functions set ustate→error
+only if they couldn’t write data from their buffer
+due to an I/O error, which doesn’t seem recoverable to me.</p>
+</div>
+<div class="paragraph">
+<p>Only the parse_endian_bool functions set pstate→error
+if they read an integer which doesn’t match either true_rep or false_rep
+when an exact match to either is required.
+If we decide to implement backtracking and retrying,
+they should call fseek to reset the stream’s position
+back to where they started reading the integer
+before they return to their callers.
+Right now all parse calls are followed by
+if statements to check for error and return immediately.
+The code generator would have to generate code
+which can advance the stream’s position by some byte(s)
+and try the parse call again as an attempt
+to resynchronize with a correct data stream
+after a bunch of failures.</p>
+</div>
+<div class="paragraph">
+<p>Note that we actually run the generated code in an embedded processor
+and call our own fread/frwrite functions
+which replace the stdio fread/fwrite functions
+since the C code runs bare metal without OS functions.
+We can implement fseek but we should have a good use case.</p>
</div>
</div>
<div class="sect2">
@@ -155,8 +193,7 @@ and structuring our comments that way.</p>
<h3 id="dsom-fixed-getter">DSOM "fixed" getter</h3>
<div class="paragraph">
<p>Note: If we change runtime1 to validate "fixed" values
-like runtime2 does, then
-we can close <a
href="https://issues.apache.org/jira/browse/DAFFODIL-117";>DAFFODIL-117</a>.</p>
+like runtime2 does, then we can resolve {% jira 117 %}.</p>
</div>
</div>
<div class="sect2">
