Scripting Command to Prevent Scripting Error Dialog Display

[Zardoz2293]

Humbling requesting consideration for a scripting command to prevent the scripting error dialog displaying when a scripting error is thrown to allow the writer of the script greater theoretical control and handling of any potential errors generated.

[bdeshi]

+1!

I'd asked for this epochs ago...

[highend]

Useful request, imho.

+1

[TheQwerty]

-1

Hiding the error dialog doesn't address the actual problem.
Further, not showing the error is presumably only part of your issue since it does nothing to cover how a script can be made aware that such an error occurred.

Well-thought out wishes on how scripters can avoid the error dialog - script command to determine if a file is in use, better error handling by individual commands, etc. - are better than a head-in-the-sand approach.

[PeterH]

Very much YES to the statements of TheQwerty

Basically you can wish this for an explicit situation, but never in general.

Especially here, where the trigger is with renameitem() - here the return value at least will show whether a rename occured or not, and the script *can* show some reaction. (This *is* a special situation!) This differs from command to command, from operand to operand, and from situation to situation.

[bdeshi]

Don is somehow getting an error code (generic sometimes) for most all situations because he can generate appropriate alerts.
Exposing this to scripters* so that we can go around the error situations is, I think, better than spamming the end-user with bright yellow scary stuff.

most languages return error codes to the programmer, why not xys?

* of course it's all up to Don. It might be difficult or more trouble than it's worth...

[Stef123]

...so that we can go around the error situations is, I think, better than spamming the end-user with bright yellow scary stuff.

Definitely true for end uses like me who mainly run already existing scripts. "Scary" is not exaggerated but very appropriate. I don't mind OK-ing out of a script with more or less graceful exits. The infamous debug window, however, still horrifies me when it comes up.

[TheQwerty]

Don is somehow getting an error code (generic sometimes) for most all situations because he can generate appropriate alerts.
Exposing this to scripters* so that we can go around the error situations is, I think, better than spamming the end-user with bright yellow scary stuff.

most languages return error codes to the programmer, why not xys?

Which I view as very different from what is being wished. This particularly wish seems to center solely around not displaying the error dialog and offers no thoughts on how the script can then detect or respond to failure. It is seems like nothing more than a putHeadInSand; command.

What you suggest gets more into requesting the script commands and functions act in ways which do not display XY's error dialog, but instead return sensible information so that the script author can act or display the error appropriately. This is something I fully support.

My opinion for the best scenarios is:
1) We have commands and functions which allow us to detect and avoid the error dialog in as many cases as possible (detect a file is in use before attempting a rename).
2) Commands which could show the error dialog should be turned into functions. (And then...)
3) Functions which could show the error dialog should be improved so that they return error details instead of the dialog.
4) If any error dialogs remain then a try-catch block should be added to the grammar and available to scripters. When inside the try instead of showing the error dialog XY would jump to the catch block and make some XY-vars <errMessage>, <errFunction>, etc. available with pertinent information. Unlike most try-catches I do not believe we need to be able to catch specific errors at this time and can thus have it catch all exceptions.

[bdeshi]

Don is somehow getting an error code (generic sometimes) for most all situations because he can generate appropriate alerts.
Exposing this to scripters* so that we can go around the error situations is, I think, better than spamming the end-user with bright yellow scary stuff.

most languages return error codes to the programmer, why not xys?

Which I view as very different from what is being wished. This particularly wish seems to center solely around not displaying the error dialog and offers no thoughts on how the script can then detect or respond to failure. It is seems like nothing more than a putHeadInSand; command.

I see the source of confusion. You see I have assumed the OP's wish is the same as mine because he posted this < http://www.xyplorer.com/xyfc/viewtopic.php?f=2&t=13278 > very recently and the topics are clearly wound with the same thread.

[ed: bad link]

[Zardoz2293]

-1

Hiding the error dialog doesn't address the actual problem.
Further, not showing the error is presumably only part of your issue since it does nothing to cover how a script can be made aware that such an error occurred.

Well-thought out wishes on how scripters can avoid the error dialog - script command to determine if a file is in use, better error handling by individual commands, etc. - are better than a head-in-the-sand approach.

SC renameitem throws "The process cannot access the file because it is being used by another process." error message during execution. So what's the scripting procedure to test for the file used by another process?

[PeterH]

Ah - here's that thread. Searched but didn't find
Have thought about it - and had a situation myself. (See example getkey() below )

So you may see this one command - but you are right: the situation can be generalized.

Fact: there are script commands and functions that, in some error situations, show some error info and then abort the script.
It would be fine if, by some means, this could be avoided on request of the script.

The idea:

- create some XY-internal variables, like
<rc> 0 = OK, 1-3 = error level
<rc2> numeric code to define what error occured (meaning dependent on failing command)
<msg> text message explaining the error
<roe> State of ReturnOnError (see below)

- and create a new command ReturnOnError(x), with
x = 0: Abort on Error, as is today
x = 1: Return on Error, giving return info as signalled by the variables
x = empty: no change (to only read state)
Return = State before execution
*only valid during execution of the current script*, default = 0! (Security!)
(Even in a subscript: reset to 0!)

With this:
- a script can signal that it will handle all errors that a command/function may see
- it can be set/unset by command, or for a complete script
- the script gets the means of reacting however it wants to

Example for <rc> for getkey():
0: all OK
1: key/section doesn't exist
2: file doesn't exist
3: invalid parameter
for <rc>=1, <rc2> might signal 1=nokey, 2=nosect

This would need 2 groups of change:
1) general: defining the variables and the function
2) then expanding each command/function supporting it.
To 2) this can be made step by step: there might be commands where user will expect it generally, and there are commands user actually miss it, like renameitem() and getkey().

Of course, this is only meant as an example - details as names etc. might be changed.

What are your thoughts?

Edit: should I move this to the Wish "Scripting Command to Prevent Scripting Error Dialog Display"
Or does a moderator do that?
[mod: Done!] [Peter: thanks!]

[Zardoz2293]

Fact: there are script commands and functions that, in some error situations, show some error info and then abort the script.
It would be fine if, by some means, this could be avoided on request of the script.Fact: there are script commands and functions that, in some error situations, show some error info and then abort the script.
It would be fine if, by some means, this could be avoided on request of the script.

It's really self-defeating if each script command and function isn't hardened as to prevent a dialog on error popup, unless the script writer specifically requests the error dialog behavior to occur on an error. In all cases an error status should (needs) to be returned indicating the result. Documentation should exists for each script command and function showing all of the possible error return codes and all of the possible error dialog popup error messages so the script writer can efficiently write the script correctly the first time with minimal investment. IMO, as awesome as XY is, this limitation, requires me to move-on and find another solution or write my own. You say, you've got to be kidding, you can't possibly write a tool like XY to provide your needs in less time than you could find a workaround for your scripting concerns. It's all about reliability, productivity, and minimal maintenance coupled with resolving concerns as quickly as possible. Thank you gentlemen for your feedback, much appreciated.

[autocart]

+1 for a better solution of error handling