How to configure test run conditions

Obviously, there is another solution to your problem if you want to write it as code.  Taking the same four functions I mentioned before, I did a bit of rework. This, effectively, does the same thing.  Likewise, if you are using Keyword tests, you could build similar logic.  You don't even need to use the "try catch" logic at all... just embed tests within tests with if/then/else logic wrapped around them to properly detect whether the sub-test should be run. This is the beauty of a tool like TestComplete... you can, potentially, organize your tests using any combination of the three techniques and end up with a REALLY cool suite of tests.

function TestA(isError) {
    try {
        if (isError) {
            throw 'Got an error in Test A';
        } 
        else {
            Log.Message('No error in Test A');
            TestB();  
        }
    }
    catch (e) {
        Log.Error('rasied an error: ' + e);
    }
}

function TestB() {
    Log.Message('Ran test B');
}

function TestC(isError) {
    try {
        if (isError) {
            throw 'Got an error in Test C';
        } 
        else {
            Log.Message('No error in Test C'); 
            TestD(); 
        }
    }
    catch (e) {
        Log.Error('rasied an error: ' + e);
    }
}

function TestD() {
    Log.Message('Ran test D');
}

function RunAll() {
    TestA(true);
    TestC(false);
}

Kind of depends what you mean by passed or failed.

If your test catches that it has failed and logs something accordingly, then your code above should be fine.

But if the second one fails and causes the code to throw an error, then is that what you want to handle?

I've done some Python, but not within TestComplete. The way I did it before, where a main loop was handing off to various smaller functions was simply to wrap the function calls in the loop within a try/except.

So in your case, something along the lines of:

def RUNALL():
param= ['P','Np','Pm']
number=1
year=16
for p in param:
     try:
         SprAddModify.SprAddModify(p,number,year)
     except:
         >> Log some sort of bug/failure here <<
         >> Maybe also do some sort of application state tidy up? <<

... should be the bare minimum required to keep it moving I would think?

Ah right. We're into the realm of how TC errors are handled (or not) in Python.

Which I know nothing about I'm afraid. So I'll leave this one to others.

I tend to write in all my own error handling anyway. I don't want automated scripts coming to a stop due to an error, because I know they can, and will, happen.

So in your case, I'd put in a check against the top level item you'll be using - the MDIWindow("Sprawa") by the look of it - and if it doesn't exist, drop out of the routine after logging an error.

So inside SprAddModify ...

def SprAddModify(rep,number,year):

if (<top level object is present>) then:
        date_w='01012016'
        SprReg.SprReg(rep,number,year)
        SprAdd(date_w)
        SprOpen(rep,number,year)
        SprCheck(date_w)
else:
        Log an error
        Return

(Syntax and formatting are not correct .... it's just example logic)

Like I say, I tend to have all the automatic error stopping switched off and rely on my own error handlers. My scripts have always had loads of error handling and validation built in anyway as they are keyword + data driven by other users. Which means there is tons of scope for the user to introduce bad calls and/or data so it has to be able to cope with pretty much anything.

It's more work, but it's also more robust once that work is done.

1. You can catch an error while it recorded to the log >> 

It is useful, if you don't know where exactly expect the error.

2. If you know the weak points of your application, you can expect the error using the last operation result.

E.g you have some checkpoint - aqObject.CheckProperty(...) It will return True if passed and False otherwise.

So you can wrap your steps like:

result = aqObject.CheckProperty( ... )
if result:
    do_something_1()
else:
    do_something_2()

3. Write your own error handler like Colin_McCrae said.

Also take a look at the Handling Events >>

If you need to break a loop, you can use a kind of "flag" variable, which will change its value if some error occurs. 

def listen():
    if Project.Variables.flag:
        Project.Variables.flag = False # <-- reset variable to initial state
        return True
    else:
        return False


def GeneralEvents_OnLogError(Sender, LogParams):
    Project.Variables.flag = True


def yourTest():
    while not listen():
        step1()
        step2()
        step3()

    other_steps()

The idea: if some error will happen during yourTest() , OnLogError event will assign flag variable as True and you will exit from the loop.