shanedell opened a new issue, #671:
URL: https://github.com/apache/daffodil-vscode/issues/671

   A parse error occurring may well want to stop things from terminating and 
allow various client/server interactions by the user to better understand the 
failure. 
   
   The ability to move backward in time is typical - when we debug using just 
trace output from the CLI debugger scrolling backward to see what happened 
before the most recent error is definitely commonplace. Particularly important 
for debugging with bigger data files. We debug against files with hundreds of 
records/messages in them. A failure may result in wanting to look backward at 
successful parses that happened well before the record/message causing the 
specific failure.  Often the specific error isn't really relevant because the 
parse went off the rails well before the specific thing that ultimately created 
the parse error that ended the parse. The evidence of it going off the rails is 
what you want to find. 
   
   In the GUI debugger, some analog to this has to be available. Breakpoints 
and stepping help, but don't entirely eliminate the need for this. 
   
   Certainly an unparse error would not want to cause termination of the server 
session. There's so much state to interact with in the unparser it's really 
much richer. 
   
   Eventually I'd expect the server session to remain operating indefinitely 
and an explicit command would be sent over telling the server to restart a new 
parse/unparse, and only at that point would the state of the current action be 
lost and things be reset. Even closing the client should send a command to the 
server telling it to shut-down in orderly fashion. 
   
   Once started, I suspect that only an abort within the server, loss of 
connection to the client (due to client abort/crash), or an explicit shutdown 
command should end the server session.
   
   _Originally posted by @mbeckerle in 
https://github.com/apache/daffodil-vscode/pull/666#discussion_r1232598964_
               


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to