gnucobol-debug icon indicating copy to clipboard operation
gnucobol-debug copied to clipboard

FR: improve error handling

Open GitMensch opened this issue 5 years ago • 1 comments

I've tried to "break" the extension by different means.

1st: bad code + run --> result: compile messages in Debug Console; source links can be followed, all fine (ideally: auto-activate the debug console) 2nd: bad cobc parameters in launch.json + run --> result: cobc error message in Debug Console, all fine 3rd: bad cobc executable specified in launch.json --> result: nothing, Debug Console stays clean but should have an error message shouldn't it be found in the the "Tasks" pane? Shouldn't all 3 issues have output in the task pane, not in the debug console?

In general it would be nice to have some output for checking the state of the extension. bitlang has a separate "COBOL" pane which specifies here:

Extension Information:
 Extension path    : /home/user/.vscode-oss/extensions/bitlang.cobol-6.2.13
 Version           : 6.2.13
  Search directory : /tmp/gnucobol-3.x
  Invalid Search directory : /tmp/gnucobol-3.x/CopyBooks

 - Parsing /tmp/gnucobol-3.x/extras/CBL_OC_DUMP.cob   (38.48ms)

I guess any real errors would be found here, too. Furthermore there is an "Extensions" pane (but it does not show any output on this machine).

GitMensch avatar May 03 '20 18:05 GitMensch

Follow-up to the 3rd point from above: Just tried to use this extension on a machine where the cobc executable was moved to another place - debugger starts (should error instead) and the only thing one could see (if one knows to check this) is the protocol for the window:

[renderer1] [error] spawn cobc ENOENT: Error: spawn cobc ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:264:19)
	at onErrorNT (internal/child_process.js:456:16)
	at processTicksAndRejections (internal/process/task_queues.js:81:21)

So "somewhere" early (I guess in the parser) there is a missing check now (earlier we still got a "failed to launch COBOL debugger" message instead.

... and I still suggest the "real fix" to be splitting of the compile and debug parts into two different steps - the first as (auto-created) task and the second as launch configuration which depends on that task.

GitMensch avatar Feb 01 '21 12:02 GitMensch