Jump to content

Error Description


Recommended Posts

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)

Link to comment
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.

Link to comment
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
Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

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
Link to comment
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.

Link to comment
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

Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...