Try(expression) no catch block, return 1 if no error

[neogna2]

Wish: Try(expression) with no catch block. Instead return 1 if the expression executed without error and return 0 on error.

Benefits: shorten code and use Try() with precision on steps inside larger expressions.

Current code where we want to proceed on non-error but have no need for catch

Code: Select all

Try a
catch
    return
MsgBox 1

could become

Code: Select all

If !Try(a)
    return
MsgBox 1

or

Code: Select all

If Try(a)
    MsgBox 1

This code where we fall back to alternatives on error

Code: Select all

try a
catch {
    try b
    catch {
        try c 
        catch {
        }
    }
}

could become

Code: Select all

If !Try(a)
    If !Try(b)
        Try(c)

or

Code: Select all

Try(a) || Try(b) || Try(c)

This wish was floated earlier but now gets its own wish post for visibility and discussion.

[iseahound]

The point of using try instead of if is to force the programmer down the try/catch/finally chain due to an explicit throw.

In other words:

1. You are wrapping a built-in function. Lexikos has specifically intended this typed error to be thrown, therefore you should address it, because it's a feature of the language.
2. You are writing your own code, and should stop using "good practice" throws because you would rather use if/else. So start returning False or 0 instead.

You could implement nice-try https://www.npmjs.com/package/nice-try?activeTab=readme
You could force the try-catch logic into a for-loop.

Code: Select all

for f in funcs
   try f()
   catch
      continue
   else
      break

You could start using Gotos.

Code: Select all

try a()
catch
   goto b
else goto end
   
b:
try b()
catch
   throw
else goto end

end:
MsgBox

[neogna2]

Thanks for describing the general case for Try Catch and for suggestions. The nice-try link was fascinating. I suppose this kind of wish/discussion crops up in many languages.

Try Catch is often useful and Lexikos makes many wise design decisions. v2 throws more errors than v1, a difference that made me at first annoyed but now thankful. It really helps with troubleshooting/debugging.

Still, I persist to think a shorter Try() would sometimes be a good fit. Kind of like how ternary and fat arrrows have their use, even though they too can be overused.

For example sometimes I use ControlGetText and other ControlGet___ where I only need to halt the code (with a return) if the target control isn't found and otherwise proceed. No need to catch anything, since there's no underlying mistake or issue that needs to be fixed in the code. Just my hotkey script doing things conditional on controls being present in some other app's window (for example a sidebar being visible or not) and otherwise do nothing. I wish I had Try() in such cases.

[iseahound]

Yes, there are a few errors that can occur as a result of side-effects on windows. Notably anything involving the special variable "A" seems to have a small yet non-zero chance of failing for some reason and deciding to throw a TargetError window not found.

I think my main point is that Lexikos designed the language to be more explicit as a feature. So your proposal would reduce AHK back to the v1 behavior of ignoring errors.

On the other hand, I think try() returning something just adds flexability to the language. It's certainly interesting, as you can see by the 10 million weekly downloads of nice-try.

[neogna2]

One type of objection to the Try() wish would be to ask for use cases and for each use case suggest either an existing better way to do it or a better wish.

For the Try(ControlGetText) use case an alternative wish could be for a ControlExist function that returns 0 if the target control isn't found. (Previously discussed)

[lexikos]

Related: [Wish] Try() Expression returning Unset - AutoHotkey Community

As for ControlExist,
https://github.com/AutoHotkey/AutoHotkey/pull/244
https://github.com/AutoHotkey/AutoHotkey/tree/controlexist

[iseahound]

One way this might be useful is in:

Code: Select all

assert try WinExist("A")

because most functions don't have standardized "success" values, it's better to test for errors. If functions return "" or unset by default, then this isn't a useful value to check. If try reduces errors to 0 or 1, then checking it's truth value via assert might be useful if ever added to the language.