What is the use case for this enhancement? ie. What problem are you trying to solve?
Currently, transports do not have a defined way to indicate that they failed to call XMLSERVICE. These types of failures would include, eg.
HttpTransport failing to connect to the remote endpoint
Missing stored procedures for DatabaseTransport
Missing xmlservice-cli utility for the SshTransport
Error loading XMLSERVICE in DirectTransport
...
Describe the solution you'd like
I think we should have a defined Exception class for transport errors defined in itoolkit.transport. If a transport receives an error while attempting to call XMLSERVICE, it could throw this error. If it has already caught an exception, the caught exception could be added as the cause of the thrown transport exception if applications want more details. Transports could subclass the main exception if they need to, but I think that may be unnecessary.
# itoolkit.transport.exception.py
import exceptions
class TransportError(exceptions.StandardError):
pass
# test.py
from itoolkit.transport import DirectTransport, TransportError
from itoolkit import *
tk = iToolKit()
transport = DirectTransport()
try:
tk.call(transport)
except TransportError as e:
print(e)
I partially implemented this in 030b930e0a27242dafc4ac9ca026d27b3524f517. There's now a TransportClosedException. Might be worth adding a base TransportError and re-basing the current exception on it.
What is the use case for this enhancement? ie. What problem are you trying to solve?
Currently, transports do not have a defined way to indicate that they failed to call XMLSERVICE. These types of failures would include, eg.
Describe the solution you'd like
I think we should have a defined Exception class for transport errors defined in itoolkit.transport. If a transport receives an error while attempting to call XMLSERVICE, it could throw this error. If it has already caught an exception, the caught exception could be added as the cause of the thrown transport exception if applications want more details. Transports could subclass the main exception if they need to, but I think that may be unnecessary.