Sign in to follow this  
Followers 0
willwatters

Error Description

11 posts in this topic

If an error occurs can a command be used to automatically find out the error description.

For example,

If winactive("Error)

MsgBox(48, "Error Found", "Unexpected Error Found")

EndIf

Instead of stating "Unexpected Error Found" is there code to use that automatically states what the actual error was (i.e. something like Err.Description which is used in VB)

Share this post


Link to post
Share on other sites



Good idea. So you can take the appropriate steps.

Usually when AutoIt reports an error it quits the script immediately after showing the error box.

If we could change that behavior by using an "option", eg: Opt("SilentError", 1), it would be great.

Share this post


Link to post
Share on other sites

Good idea. So you can take the appropriate steps.

Usually when AutoIt reports an error it quits the script immediately after showing the error box.

If we could change that behavior by using an "option", eg: Opt("SilentError", 1), it would be great.

<{POST_SNAPBACK}>

that would be great...i run long processes..and if theres a prob when im writing it..i have to do everything back manually to restart after fix...if i could perhaps even ski[p the error

Share this post


Link to post
Share on other sites

Exactly.

@developers:

What do you say?

Share this post


Link to post
Share on other sites

Exactly.

@developers:

What do you say?

There shouldn't be any "fatal" errors that can happen under normal conditions - there used to be with some Reg related things but we got rid of those. It should just be syntax errors and the like, so it would be a bit daft having the facility to trap those!

Opt("silentError", 1)

If jjkfd *&09

If @error Then
...

Makes no sense at all.

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

There shouldn't be any "fatal" errors that can happen under normal conditions - there used to be with some Reg related things but we got rid of those.  It should just be syntax errors and the like, so it would be a bit daft having the facility to trap those!

Opt("silentError", 1)

If jjkfd *&09

If @error Then
...

Makes no sense at all.

<{POST_SNAPBACK}>

No, no, no. Ofcurse not.

This is better.

Opt("silentError", 1)

If jjkfd *&09

Func OnFatalError()
   Select
      Case @FatalError = 15 Then
       ;Update the @FatalError macro with an error number.
       ;The error numbers will have to be documented
   EndSelect
EndFunc

The advantages:

- save open files (ex. text in a GUI edit box)

- when you have a TCP connection using Larry's DLL, you can close the connection the right way. Currently it will never reach OnAutoItExit when something goes wrong.

Edited by SlimShady

Share this post


Link to post
Share on other sites

For those who know how to use the langage correctly with proper checks for returns, no fatal errors should happen. With a good design, even RunErrorsFatal will account for all other problems.


Who else would I be?

Share this post


Link to post
Share on other sites

Sorry I dont understand. I want to capture the description of an error. For example, an application does'nt load up so my script will detect the error and the description of the error (application failed to load.) Does Opt("SilentError", 1) do this?

Share this post


Link to post
Share on other sites

You have RunErrorsFatal. This can be used to determine whether to have a fatal error or a silent error when a Run or RunWait couldn't be completed for some reason (i.e. application couldn't load).

This is the only real thing you can, and need to trap errors for in this way. You can't really trap errors during the execution of another program, since you can't tell how it would error, and you'd ideally need some sort of debug tool to plug into it.

Share this post


Link to post
Share on other sites

You are all right. If you understand the AutoIt syntax and you perform some tests before using the script in a working environment, you don't need this.

Tip:

Check your script with tylo's Au3Check.

Share this post


Link to post
Share on other sites

i think he wants to trap program errors not autoit errors...For example a program gets fatal/non fatal error..he can check what the error is and its description....either builtin description or displayed text.

I suppose u can kinda do that now by checking for existing windows and window text but u wont know if its an error or not..cuz u cant get its decription. It would be nice if windows are identified as error windows or event windows...etc I dunno..i dont have too much use for it right now because i know what windows to expect - errors and not

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0