try catch I still don't get it...

[Mr.Peanut]

I still do not understand the usage of try-catch. Which statement in the try block below throws an exception and why?

Code: [Select]

// Deposit button.
try
{
private ["_depositStr", "_depositAmount"];
_depositStr = ctrlText SPON_BANK_DEPOSIT_VALUE_IDC;
_depositAmount = parseNumber _depositStr;

_canDeposit = ((str _depositAmount) == _depositStr) and
(_depositAmount > 0) and
(_depositAmount <= SPON_playerCashBalance) and
SPON_IS_INTEGER(_depositAmount);
}
catch
{
_canDeposit = false;
};

[Spooner]

Nothing in that code throws an exception (that can be caught by catch or the ArmA error handling system). Even I wrote code in naive ways back in the day ;P

In other languages, a command like parseNumber would raise an exception if you gave it bad data, like "Cheese", however in ArmA, you just get given the value 0. The code still works correctly, however, since a value of 0 denotes that you can't deposit the amount anyway. The expression, "(str _depositAmount) == _depositStr", checks this anyway, since "0" (value parsed) would not be equal to "Cheese" (value input)! Talk about belt and bracers!

Anyway, it is through a lot of daft mistakes like this that I learned how things work, so I can't complain. Sorry if I confuse you all sometimes, but don't be afraid to query things like this when they do leave you lost...

[Mr.Peanut]

So for that example the try catch dose nothing? It seems to me that try-catch as it stands now, is nothing more than an if-then-else. Even with your past "nofish" example I don't get it.

[i0n0s]

try-catch only catches custom exceptions someone throw.

[Mr.Peanut]

Okay. The Biki article on Exception Handling gives a clear example. My brain fart has dissipated.

[Spooner]

It makes more sense when you use throw to unwind the call stack, since the minimal examples you get could usually be written much simpler anyway:

Code: [Select]

_fn1 =
{
   call _fn2;
   // Do stuff...
};

_fn2 =
{
   call _fn3;
   // Do stuff...
};

_fn3 =
{
   if (x > 0) then { throw "My frog died" };
   // Do stuff...
};

x = 5;

try
{
    call _fn1;
    // Do stuff...
}
catch
{
   hint _exception;
};

If x is greater than 0, as it is in the example, then all the "do stuffs" will be avoided when the exception is thrown in _fn3, without the need to manually have a lot of error states returned and checked continuously in every function. The other option is to handle errors when they occur, but that ends up having inconsistent messaging systems and is again, cluttering up your code with lots of repeated code.

Now you've brought it up, I think I should probably introduce try/catch properly into SPON, but I'm worried about the cost (try/catch management is usually a bit slow). I'll think on it some more...

[i0n0s]

If the above is true, then we can use throw as alternative to exitWith to terminate a script since the behaviour of exitWith is undefined when not using it in a scope.

[Spooner]

Well, exitWith will always break out of the innermost block, but people often do assume it will exit the script entirely, like exit in SQS (but then, SQS only has a single scope, so really it is the same thing).

That is a good point about using at as a true "exit" command. If you have an error state, you are better stopping the script than messing about, and if your, or another, script wants to catch it then that is even better.

[i0n0s]

If you use exitWith on the last block, the script itself like:

Code: [Select]

//do something
if (bla) exitWith {...};
//do something otherthe behaviour is undefined:

exitWith exits the execution of a loop defined by one of commands do, for, count or forEach. When you use exitWith not inside a loops, the behaviour is undefined.

Take a look in the Biki, in the description section. There is a clarification by Suma.

If you still want to use exitWith to terminate your script then create a block for example with

Code: [Select]

{
  //your code here
} forEach [1];But this is bad behaviour and would get dropped by an optimizer.

So throw would be the solution to terminate a script in SQF.

[Mr.Peanut]

Unfortunately, the current state of knowledge is such that the only truth is what you find by testing things for yourself. Why did BI not make a true return statement? 

And what is up with scope? Here is our own comref example for breakTo, reformatted for easier reading:

Code: [Select]

scopeName "main";
while {true} do
{
   scopeName "loop1";
   while {true} do
   {
       scopeName "loop2";
       if (condition1) then {breakTo "main"};//Breaks all scopes and return to "main"
       if (condition2) then {breakOut "loop2"};//Breaks scope named "loop2"
       sleep 1;
   };
   sleep 1;
};
This example makes scopes look like the new goto. What I really dislike is that scope does not have to be clearly delimited, say by enclosure in curly braces. Surely there is more to it than that? Does this encourage better, cleaner style than using loops controlled by a boolean flag? 

[Spooner]

The arguments regarding structured and unstructured programming have been done to death. Using any sort of goto, even a "controlled goto" (like exitWith or breakto) is unstructured and "bad", but rigidly structured is always "good". I have a pragmatic approach: "Always attempt structured programming style, unless by following that style you create code which is bloated, convoluted and even harder to follow than the unstructured version". The same sort of approach should be taken to recursion: "Always avoid recursion, unless by doing so you make a significantly simpler system".