- Are there are crossover examples?
- It throws on an error (throw, handled by: try/catch/finally/OnError) or it doesn't (indicate failure by one of: function return value/function ByRef output variable/ErrorLevel/special variables for convenience like A_MsgBoxResult which was at one point in AutoHotkey v2).
- A_LastError, which uses the Winapi function GetLastError, might be set, whether you throw or don't.
- Using either/all of those is fine, but I would want to write scripts where using ErrorLevel is not necessary.
- In the past, AHK didn't have 'throw', I wrote all of my functions to return error values (via return values or via ByRef output variables), and not use throw. I got used to *thinking carefully* and *taking responsibility*. But, safety is probably the most important thing in programming, and I'm getting used to the idea of 'the safer the better'.
- Also, code commonly gets revised, and it's easy to introduce new bugs, so, 'safety first'.
- I'm neutral re. try/catch/finally etc, I haven't minded using them, e.g. they're commonly used with Internet Explorer, MS Excel and in the Acc.ahk library.
- Perhaps it's useful, when using operators/mathematical functions, to throw versus return blank strings. But then again, the entire formula resolving to a blank string, if there was at least one error, might be fine.
- Throw could encourage lazy coding: instead of writing proper code to handle errors, you just let them occur with the option to terminate the script or let it run.
- Although you could say throw makes things secure, guarding against amateur or lazy coders: any error must be explicitly handled by the code, or the script is terminated. That said, there may possibly be unforeseen circumstances, even for the expert.
- There may be a disadvantage in forcing a script to end, for example, some minor error (which may not even strictly be an error).
- E.g. AHK is being increasingly strict about what it considers an error. I think this is a good thing. However, I wrote my scripts to meet the old standards, and so now my scripts could end unexpectedly, and I'd lose my data. If error messages provide an option that allows you to keep running the script, then there is no problem.
- E.g. you could have a script: for each key in obj.mykey, append the key's value to a string. Before, under the old rules, if 'mykey' didn't exist, you'd end up with a blank string, now, you get an error message and the script terminates.
- E.g. before, you could depend on the value of an undefined key being a blank string, now you have to add handling in case the key doesn't exist.
- (If my script is about to be forcibly but unnecessarily terminated, I might try and grab any data from the address space.)
- Perhaps the best answer is: it's OK to use either way (throw/don't throw). But throw gives you error messages, thus more safety, however, throw without the option to let the script continue running, could be a major problem. Either way, if you knew something could have catastrophic consequences, consider showing an error message and ending the thread/process.
- One thing to consider, if your function is in a library, the function's error handling could/should match the style of error handling of any other functions.
- There was an interesting discussion here:
ErrorLevel - AutoHotkey Community
- [EDIT:] My current best advice: when any problem, that is not explicitly handled, occurs, show an error message, an error message that can be ignored. If it's a serious error, show an error message and end the thread/process. So, optional exit versus forced exit.