State of MIR_context after error func is called?

[snej]

I like the simplicity of Mir’s error handling. I’m working in C++, so I register an error func that throws an exception, which is a lot easier than having to check an error return value from every API call!

However, I’m unsure what calls on the context are allowed after an error. Should I assume the context is in an inconsistent state, and I have to call MIR_finish and start over? Or does Mir clean up before calling the error func?

It looks like most errors represent bugs in the application, like opening two functions or passing the wrong operands to an instruction. Those shouldn’t occur in real use, so I’m fine just bailing out.

But there are some cases where unforeseeable errors could happen, especially in I/O. What happens if mir_read reads a corrupted file, or mir_write hits a disk-full error? As an app developer I can’t just abort; I need to recover. Throwing away the MIR_context would be very awkward since all the JIT-ted code would suddenly be gone...

[vnmakarov]

Should I assume the context is in an inconsistent state, and I have to call MIR_finish and start over? Or does Mir clean up before calling the error func?

I'd say you should assume the former.

People already raised analogous questions about error handling which now is not adequate. Changing it will change MIR API and this would mean a new major version. I'll try to redesign and reimplement error handling for the next release which will be based on bbv branch as the branch already contains considerable API changes.