Exceptions in TUI commands

[h-krishnan]

If I have the following commands in a script file, and the first line throws an error (e.g. file does not exist), should the second line get executed, or should the script execution abort with exception at that point? At present, because the TUI commands are executed asynchronously, the second line does not know that the first line has thrown an exception and so gets queued.

session.tui.solver.file.read_case(r'elbow.cas.h5')
session.tui.solver.file.read_data(r'elbow.dat.h5')

[h-krishnan]

I am wondering if we should add an additional argument "wait" to commands with default = True. If True, maybe future.result() should be returned. If False, the future object could be returned.
Before queueing any new command, should we check for future.result() of previous command which is run with wait = False? Once future.result() of previous command is accessed (and exception thrown), we could reset it so that the exception is not thrown again.

execution of command (or any remote operation?):
Check if future object of previous command exists and check if it has thrown an exception.
If exception thrown, exit
Queue command and get future object
If wait = True, return future.result()
Else store future object for reference

[dnwillia-work]

yeah, that sounds sensible to me. I think if we are running Python interactively then it should behave the way you describe in the opening post.

[h-krishnan]

On second thought, I wonder if we should even run the commands in async mode. Is it more natural to expect that a command will finish executing before returning, and the return value is available? We could give examples of how the user might be able to send commands to different sessions in parallel using threading, but it could be a user decision. I feel this will be more amenable to clean exception handling.

[dnwillia-work]

For the most part I would think so though it begs the question why we have asynchronous objects at all.

[seanpearsonuk]

@dnwillia-work the motivation for having asynchronous calls is to free the console, so that the user can carry out multiple unrelated tasks. I tend to agree with @h-krishnan though that we could make the commands themselves synchronous and leave it to the user to employ threading on top.

[dnwillia-work]

Yeah, that makes sense. I guess in the opening post, if the first line throws an error that needs to put the session object into an error state that can be queried right (instead of throwing an exception). What happens currently? I've not tried.

[seanpearsonuk]

@dnwillia-work calling result( ) on the future synchronizes so that includes throwing any exception that would have been called. I'm not seeing result() throw an exception in the present scenario. Also if I change the tui commands to be synchronous, I still don't see the error in the client. I thought there was an issue where we were planning to parse TUI command errors from the streamed transcript but I don't see it in the list.