mbeckerle commented on code in PR #666:
URL: https://github.com/apache/daffodil-vscode/pull/666#discussion_r1232598964
##########
server/core/src/main/scala/org.apache.daffodil.debugger.dap/DAPodil.scala:
##########
@@ -399,7 +404,7 @@ class DAPodil(
for {
variable <- launched.debugee.eval(args)
_ <- variable match {
- case None => session.sendResponse(request.respondFailure())
+ case None => session.terminate("eval failed")
Review Comment:
Yeah, you got it. That was my point: 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.
--
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]
