No difference in UI between NotebookCellOutputItem.error vs. NotebookCellOutputItem.text

[anthonykim1]

When defining the execution handler to register notebook controller from the extension side (Python extension in this specific case), I've noticed there was no difference between the output in terms of the execution message UI or the executing cell itself, of the API NotebookCellOutputItem.error versus using NotebookCellOutputItem.text.

I thought perhaps maybe there would be even a slight difference when there is some sort of failure (other than the red circle that marks the failure of execution), but do not seem to find any obvious differences in terms of the style of the error(I suspected maybe it would handle the coloring of the error output better so that messages are non-white and of red color) output themselves. Would this be a bug?

Is everything just basically dependent for implementer of the execution handler to correctly call exec.end(true or false);

Was reading the API doc and came across application/vnd.code.notebook.error mime type, but wasnt too sure what this .error mime type would be.

[DonJayamanne]

Is everything just basically dependent for implementer of the execution handler to correctly call exec.end(true or false);

Yes. There is no hard and fast rule on how you use the API.
The API is always available for anyone to use how they choose.
E.g. even if exevution fails, you can use exec.end(true), thats totally upto the implementation (extension author).
However in the Jupyter execution world, if execution fails, then we expect the cell to be marked as failed and the output to contain certain information that contains the details of the error (hence the error output).

As for the coloring of outputs, I'll leave that for @rebornix @amunger
However if there are errors in the output and the execution has failed, then the error outupt needs to be used and status of false when calling end.

[anthonykim1]

@DonJayamanne Thanks for explaining this.

However in the Jupyter execution world, if execution fails, then we expect the cell to be marked as failed and the output to contain certain information that contains the details of the error (hence the error output).

I also thought I should follow using vscode.NotebookCellOutputItem.error instead of .text but I after trying out both of the API call, I could not really distinguish if there was any user facing difference in UI/output(assuming we were properly calling exec.end(false) or exec.end(true) depending on the output). Hence why I was confused if I really had to use one(.error) over another(.text) depending on success/failure scenario. I do realize that exec.end(false) or exec.end(true) should be called to show appropriate check mark or red X mark so that was intuitive and visibility.

Perhaps we are more recommended to use attach error message via result.error rather than result.output as more of style guideline for better readability and organization?

As far as the colorization of the output, would there be way can control from the extension side?

[amunger]

The colors in the error outputs from IPython kernels are provided by IPython using ascii colors, e.g.

"traceback": [
      "\u001b[1;31m---------------------------------------------------------------------------\u001b[0m",
      "\u001b[1;31mZeroDivisionError\u001b[0m                         Traceback (most recent call last)",
      "Cell \u001b[1;32mIn[18], line 2\u001b[0m\n\u001b[0;32m      1\u001b[0m \u001b[38;5;28;01mif\u001b[39;00m (x \u001b[38;5;241m>\u001b[39m \u001b[38;5;241m-\u001b[39m\u001b[38;5;241m1\u001b[39m):\n\u001b[1;32m----> 2\u001b[0m     \u001b[38;5;28mprint\u001b[39m(\u001b[38;5;241;43m1\u001b[39;49m\u001b[38;5;241;43m/\u001b[39;49m\u001b[43mx\u001b[49m)\n",
      "\u001b[1;31mZeroDivisionError\u001b[0m: division by zero"
     ]

produces

As far as the different API options, .error will take a javascript Error object as the parameter and create an output with the error mimetype that will use that specific output renderer, whereas .text just takes a string and can be provided any mimetype. There are some differences in how the mimetypes are rendered, but also .error just makes it easier to simply pass an Error object and it will put the traceback in the correct place AFAICS.