Error method is noncompliant to Jupyter protocol

I posted this issue on the octave_kernel repo, but after digging into the source, I discovered it may be generic to all kernels based on Metakernel. So here’s the issue description again: So when a kernel errors out, you should be sending back an execute-reply like this:

{
    #...
    'content':{
        'status':'error',
        'ename':<your_error_name>,
        'evalue':<your_error_data>,
        'traceback':<your_traceback>
    }
    #...
}

That way Jupyter can process that as a proper error and not just assume it is any old STDOUT. Right now it would be a the easiest (?) fix to just rename what you are already returning to ‘traceback’ and insert some dummy values for the fields that you can’t get easily.

It would be really awesome if this were fixed because it’s breaking my use case!

[JMurph2015]

So the train has kinda left the station for me to do this on my internship time, but I can probably hack around a little and talk about what this should look like on my free time. Maybe we should make an empty PR or something to talk out how this should look?

[JMurph2015]

I had a pretty decent idea just a few minutes ago that might help us all out. If we called the repl in question with a bash pipe that padded stderr with somewhat long sequences of unprintable characters (that we know), then we could just regex on those sequences later and if they were long, uncommon, and unprintable, then it’s extremely unlikely to be something a user cared about seeing, and I can feel confident in calling it an actual error.