[GitHub] [daffodil-site] mbeckerle commented on a change in pull request #44: Update runtime2 todos

[GitBox <gi...@apache.org>]

mbeckerle commented on a change in pull request #44:
URL: https://github.com/apache/daffodil-site/pull/44#discussion_r614415205



##########
File path: site/dev/design-notes/runtime2-todos.adoc
##########
@@ -38,108 +38,42 @@ in order to avoid duplication.
 
 === Error struct instead of error message
 
-To make internationalized error messages
-easier to construct when an error happens,
-we should return an error struct with some fields
-nstead of an entire error message string.
-It is easier to interpolate values into messages
-in the same function which also prints the messages.
-We still would check for errors
-by doing a null pointer check,
-although we might consider moving that check
-from parser/unparser functions to their callers
-to skip over all remaining function calls:
-
-[source,c]
-----
-    unparse_be_float(instance->be_float[0], ustate); 
-    if (ustate->error) return;
-    unparse_be_float(instance->be_float[1], ustate); 
-    if (ustate->error) return;
-    ...
-----
-
-=== Validation errors
-
-We should handle three types of errors differently:
-runtime schema definition errors,
-parser/unparser errors,
-and validation errors.
-Schema definition errors should abort parsing immediately.
-Parser errors may need to allow backtracking in future.
-Validation errors should be gathered up
-without stopping parsing or unparsing.
-We should be able to successfully parse data
-that is "well formed"
-even though it has invalid values,
-report the invalid values,
-and allow users to analyze the data.
-We probably should gather up validation errors
-in a separate PState/UState member field
-pointing to a validation struct with some fields.
+This change is almost complete.
+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.
+
+=== Different types of errors
+
+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.

Review comment:
       Stop the program .... hmmm. I think we should say we want to abandon the current parse/unparse invocation. But the application probably doesn't exit. That would depend on the recovery behavior we need. Typically this would want to reset the position in the input stream back to where it started on the data, and then return to the caller. The caller can advance by some increment (e.g, 1 byte) and try again, as one heuristic that could eventually, after a bunch of failures, resynchronize with a correct data stream after a bunch of noise bytes. 

##########
File path: site/dev/design-notes/runtime2-todos.adoc
##########
@@ -38,108 +38,42 @@ in order to avoid duplication.
 
 === Error struct instead of error message
 
-To make internationalized error messages
-easier to construct when an error happens,
-we should return an error struct with some fields
-nstead of an entire error message string.
-It is easier to interpolate values into messages
-in the same function which also prints the messages.
-We still would check for errors
-by doing a null pointer check,
-although we might consider moving that check
-from parser/unparser functions to their callers
-to skip over all remaining function calls:
-
-[source,c]
-----
-    unparse_be_float(instance->be_float[0], ustate); 
-    if (ustate->error) return;
-    unparse_be_float(instance->be_float[1], ustate); 
-    if (ustate->error) return;
-    ...
-----
-
-=== Validation errors
-
-We should handle three types of errors differently:
-runtime schema definition errors,
-parser/unparser errors,
-and validation errors.
-Schema definition errors should abort parsing immediately.
-Parser errors may need to allow backtracking in future.
-Validation errors should be gathered up
-without stopping parsing or unparsing.
-We should be able to successfully parse data
-that is "well formed"
-even though it has invalid values,
-report the invalid values,
-and allow users to analyze the data.
-We probably should gather up validation errors
-in a separate PState/UState member field
-pointing to a validation struct with some fields.
+This change is almost complete.
+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

Review comment:
       Anything static like this should assumed to be in the runtime data objects as the "static context" objects. That way we can cope with variants that both do and don't support this, e.g., a hardware/FPGA-type implementation would probably just output an error ID number logged by some device driver or such, along with a data position, and external tools would have to "humanize" these numbers using information from the schema and knowledge of the runtime data objects. But that would be offline, like a log processor. 




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org