Test Library: Program Execution Monitor output
Hello, I just plugged program execution monitor in my code and there are certain things I don't really like. First of all is not it odd to see a contradictory messages like: --------------------------- no errors detected **** error return code 1 ********** errors detected; see standard output for details *********** --------------------------- I don't really need this "no errors detected" message. Looking into code I found a way to turn it off -- I have to define an environment variable. I have a way to control this behavior. This is good. Bad news though that the way to control is quite an awkward one. I would like to have some internal control, probably overwritable via environment variable. Another concern is that I have no control on return codes in case of exceptions and runtime errors. For instance in my company all programs have to return 1 in case of failure (and 0 on success). Other return codes are no-no. I am sure there are zillions of different environments with different, often contradictory requirements for error handling. The point I am trying to make is that it is not that difficult to make Monitor more flexible, and it will increase its value tremendously. The ultimate solution would be giving user an opportunity to supply error-handling function which will print out whatever it want to, and return desired return code. Best regards, Kirill Lapshin
I don't really need this "no errors detected" message. Looking into code I found a way to turn it off -- I have to define an environment variable. I have a way to control this behavior. This is good. Bad news though that the way to control is quite an awkward one. I would like to have some internal control, probably overwritable via environment variable.
What kind of internal control you need: compile time, runtime time? And how it will be more convenient than existent one?
Another concern is that I have no control on return codes in case of exceptions and runtime errors.
For instance in my company all programs have to return 1 in case of failure (and 0 on success). Other return codes are no-no. I am sure there are zillions of different environments with different, often contradictory requirements for error handling.
The current return codes scheme seems to fit in majority of the cases. Would you need something different, as you mention in your other post, you could always use execution monitor directly. Regards, Gennadiy. P.S. Be aware of upcoming changes in the execution monitor. Check out cvs and main list for the post: "[Test] revision one".
participants (2)
-
Gennadiy E. Rozental <rogeeff@mail.com>
-
klapshin <klapshin@yahoo.com>