tuxji commented on a change in pull request #44:
URL: https://github.com/apache/daffodil-site/pull/44#discussion_r614892905
##########
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:
True, the only calls which stop the program are in daffodil_main.c
(top-level error handling) and stack.c (empty, overflow, underflow fatal errors
which should never happen). 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.
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.
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. I'll consult
one of my teammates on whether we can implement fseek but we should have a good
use case for it.
--
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:
[email protected]
