Continue evaluating other codeblocks even if a fatal error was thrown

[thangngoc89]

In education sketches like this one, the author sometimes wants to explicitly throw an error

and continue to explain the idea below. Maybe we should continue evaluating other codeblocks?

[thangngoc89]

another example in the wild:

[hcarty]

Maybe it's worth adding a "skip" option for code blocks? It could be something that only shows up when a block fails to evaluate.

[thangngoc89]

@hcarty I see. That's an interesting idea. I'll explore that route to see how complicated it's to implement

[thangngoc89]

• octachron on Discord:

For a similar purpose, the manual example generator uses an attribute when a error is expected ([@expect error])

[thangngoc89]

Let's go with the approach of adding an option to the block to say that this block is expecting to fail. And probably we should only display the option when there is an error.

Details:

• This is the condition in worker thread

  sketch-sh/client/src_analyzer/Worker_Analyze.re

  Lines 103 to 104 in fd75d69

  	hasError ?
  	[(id, result), ...acc] : loop(rest, [(id, result), ...acc]);

  to stop executing when there is an error. We can easily add an option there to keep evaluating other blocks.
• This is where the the code blocks is gathered and send to worker thread

  sketch-sh/client/src_editor/Editor_Blocks.re

  Lines 241 to 255 in fd75d69

  	let allCodeToExecute =
  	state.blocks
  	->(
  	Belt.Array.reduceU([], (. acc, {b_id, b_data, b_deleted}) =>
  	b_deleted ?
  	acc :
  	(
  	switch (b_data) {
  	| B_Text(_) => acc
  	| B_Code({bc_value}) => [(b_id, bc_value), ...acc]
  	}
  	)
  	)
  	)
  	->Belt.List.reverse;

You can put the expect to fail condition there before sending to worker