Feature - Rejected retrieve_item option to not abort on failure

[taltamir]

when retrieve_item fails it both returns true and also throws an abort.
would be great if there was an option for it to not do that.

currently available:
boolean retrieve_item( item )
boolean retrieve_item( item, int )
boolean retrieve_item( int, item )

add
boolean retrieve_item( item, boolean )
boolean retrieve_item( item, int, boolean )
boolean retrieve_item( int, item, boolean )
where the boolean value determines if it aborts or not

Here you can see the abort

> ash retrieve_item($item[Airplane charter: Dinseylandfill]); print("TEST SCRIPT DID NOT ABORT", "blue");

Searching for "airplane charter: Dinseylandfill"...
Search complete.
Searching for "airplane charter: Dinseylandfill"...
Search complete.
You need 1 more airplane charter: Dinseylandfill to continue.
Returned: false

it failed to buy the charter. so it aborted. this results in
print("TEST SCRIPT DID NOT ABORT", "blue");
not running

oddly enough having a print command wrap it gets around this

> ash print(retrieve_item($item[Airplane charter: Dinseylandfill])); print("TEST SCRIPT DID NOT ABORT", "blue");

Searching for "airplane charter: Dinseylandfill"...
Search complete.
Searching for "airplane charter: Dinseylandfill"...
Search complete.
You need 1 more airplane charter: Dinseylandfill to continue.
false
TEST SCRIPT DID NOT ABORT
Returned: void

in this case it does print:
TEST SCRIPT DID NOT ABORT

and I can also use a try finally

boolean try_retrieve(int amt, item it)
{
    //a failed retrieve command throws an abort instead of merely returning false.
    try retrieve_item(amt,it);
    finally return item_amount(it) >= amt;
}

but I think it would be better if you could control this via boolean.

 

[taltamir]

Actually now that I think about it. I think I discussed it with someone long ago and learned it was some sort of error state rather than a full abort()
which interrupts some things but not others. (a full abort() would have not been eaten by print)

So the correct feature request would be to, depending on boolean status, to not do whatever error state is causing the disruption that is preventing "TEST SCRIPT DID NOT ABORT" from showing up in the sample above

 

[Malibu Stacey]

I think this is to do with return values not being captured.

> ash boolean fail = retrieve_item($item[Airplane charter: Dinseylandfill]); if (!fail) {print("TEST SCRIPT DID NOT ABORT", "blue");}

Searching for "airplane charter: Dinseylandfill"...
Search complete.
Searching for "airplane charter: Dinseylandfill"...
Search complete.
You need 1 more airplane charter: Dinseylandfill to continue.
TEST SCRIPT DID NOT ABORT
Returned: true

Happens with lots of ASH functions.
I personally disagree with this behaviour but I wasn't even playing KoL when the ASH language was implemented in mafia.

 

[Veracity]

retrieve_item() returns true if it succeeded and false if it failed.
So, your example is a little weird.

> ash retrieve_item($item[Airplane charter: Dinseylandfill]); print("TEST SCRIPT DID NOT ABORT", "blue");

Searching for "airplane charter: Dinseylandfill"...
Search complete.
Searching for "airplane charter: Dinseylandfill"...
Search complete.
You need 1 more airplane charter: Dinseylandfill to continue.
Returned: false

> ash boolean success = retrieve_item($item[Airplane charter: Dinseylandfill]); print("TEST SCRIPT DID NOT ABORT", "blue"); success

Searching for "airplane charter: Dinseylandfill"...
Search complete.
Searching for "airplane charter: Dinseylandfill"...
Search complete.
You need 1 more airplane charter: Dinseylandfill to continue.
TEST SCRIPT DID NOT ABORT
Returned: false

ASH is working exactly as designed.

A real ABORT state cannot be captured, but ERROR state can be captured - and doing so puts you in CONTINUE state.

The intent was to recognize that ASH - "Advanced Scripting Handler" - is, as it name indicates, a "Scripting Language".

Automation in the GUI stops when an ERROR state is entered.
Ditto for CLI scripts.
Ditto for ASH scripts.
Ditto for shell scripts.

Entering an ERROR state is conceptually the same as throwing an exception in other languages.
If your Java (or python or just about any other language) does not catch the exception, it terminates your program.

Capturing the return value of a function call is ASH's way of catching the exception.

Feel free to "disagree" with this behavior - your program exits if it does not catch a severe (enough) exception - but I guess you'd disagree with a lot of programming languages, then.

 

[Veracity]

Actually now that I think about it. I think I discussed it with someone long ago and learned it was some sort of error state rather than a full abort()
which interrupts some things but not others. (a full abort() would have not been eaten by print)

So the correct feature request would be to, depending on boolean status, to not do whatever error state is causing the disruption that is preventing "TEST SCRIPT DID NOT ABORT" from showing up in the sample above

No.

retrieve_item returns false and enters an error state if it cannot retrieve the item.
If you ignore the return value, the error state will terminate your program.
If the error state is captured, it will not.

Rather than changing ASH to let you pass in a parameter to NOT return an error, if it is important to you to ignore the error and do nothing, write your own function to wrap it.

boolean my_retrieve_item(int count, item it) { return retrieve_item(count, it); )

 

[Veracity]

Here's a related feature request from Ryo_Sangnoir. You may have heard of him.

One suggestion was to have try/catch/finally, and if you had catch, you could get the error message in a variable.
Perhaps that would mean it did not get printed?
If so, that's a pretty big change.

In any case, that (open and unfinished) Feature Request is a more general request than what you seem to be looking for.

I did some preliminary work. Perhaps Ryo would like to finish it - now that he has the Power?

 

[Ryo_Sangnoir]

The feature request was implemented as much as I desired with the "catch" keyword.

The behaviour is such that you can ignore the error by:
* prepending with the catch keyword
* assigning the result to a variable
* using the expression somehow -- e.g. in an "if" or "print" or some function call

So taking the first example, you could write it as

ash catch retrieve_item($item[Airplane charter: Dinseylandfill]); print("TEST SCRIPT DID NOT ABORT", "blue");