VBScript

1. VBScript Session 12

2. What We’ve learned last session? • What is OOP and the OOP model. • What is an object, how to create an object, use methods, properties and attribures • How to set object to variables, and how to free the variables. • What is a collection and a container object. • What is COM objects, how do they defined • The FileSystem object, how to create,delete,read,copy files and directories, how to get system information. Last session was for begginers

3. Subjects for session 12 • Error Handling • On Error statements • On Error Goto 0 • On Error Resume Next • Err Object • Methods. • Properties. • vbObjectError constant

4. Error HandlingExpect the Unexpected! There are two ways of producing error-free software. But only the third will work ... Unknown Author What we anticipate seldom occurs; what we least expected generally happens. Benjamin Disraeli

5. Error HandlingWhy? • There are bugs than can eliminate an entire project. • There are also bugs that can kill people. • Reliability is a major characteristic of high-quality software. • Software should behave well in nearly every situation. • During the development process we try to avoid, detect and remove as many errors as possible. • We cannot assume that the delivered software is free of errors. Therefore, we have to think about mechanisms to protect the productive system from unacceptable behaviour while erroneous situations occurs.

6. Error HandlingGoals • We want to be prepared for the program changing into a bad state. • In most cases there will be no return from the bad state to a good state and the program has to be terminated in a controlled way. • Of course, whenever possible the program tries to get out of trouble by itself, but normally it would be very difficult to recover from a serious error situation. • During specification the boundary between the normal, abnormal and erroneous behaviour is drawn and this boundary remains visible down to the code.

7. Error HandlingGoals • We want to minimize the set of disastrous states by foreseeing these situations and thus converting them to expected situations. • An error handling concept defines which errors must be distinguished and how the system reacts to these errors. • Such a concept can be very simple or very complicated.

8. Error HandlingTerminology Fault Error Failure Causes Causes Detects Detects Exception Detector Raises

9. Error HandlingTerminology - Fault • A fault is the origin of any misbehaviour. • One can distinguish between design faults (software bugs), hardware faults, lower level service faults, and specification faults.

10. Error HandlingTerminology - Error • A user error is a mistake made by a user when operating a software system. • The system is able to react to these mistakes, because it is designed to expect such situations and it is a part of the required functionality. • The handling of those situations, which of course can be abnormal, should be treated in the user interface component of the system. • In contrast to an error, a user error (hopefully) can not result in a system crash, but like a system error, a user error normally can result in an exception raised by a system component.

11. Error HandlingTerminology - Failure • A failure is a deviation of the delivered service from compliance with the specification. • Whereas an error characterizes a particular state of a system, a failure is a particular event namely the transition from correct service delivery to incorrect service.

12. Error HandlingTerminology - Detector • Before software can react to any error it has to detect one first. • If we look at the error handling as a separate software system, errors and failures of an application are the phenomena the error handling system observes. • Thus a detector is the interface between the error and failures happening outside and their internal handling. • The number, place and kind of detectors have great impact on the quality of an error handling system.

13. Error HandlingTerminology - Exception • Generally, any occurrence of an abnormal condition that causes an interruption in normal control flow is called an exception. • It is said that an exception is raised (thrown) when such a condition is signaled by a software unit. • In response to an exception, the control is immediately given to a designated handler for the exception, which reacts to that situation (exception handler). • The handler can try to recover from that exception in order to continue at a prede-fined location or it cleans up the environment and further escalates the exception. • exceptions are not only a mechanism which can be used to handle errors and program failures.

14. Error HandlingSummary • No software system can be assumed to behave totally correct. • Even careful testing and the use of formal methods does not guarantee error-free software, hence we cannot rely on a “perfect world” assumption. • Because we cannot prevent errors we have to live with them. • The software must be able to detect errors and to defeat them with appropriate recovery techniques and mechanisms in order to restore normal operation.

15. On Error Statements • Enables or disables error-handling. • If you don't use an On Error Resume Next statement anywhere in your code, any run-time error that occurs can cause an error message to be displayed and code execution stopped. • This sample of error message generated when trying to open a file that not exists.

16. On Error Statements • However, the host running the code determines the exact behavior. • The host can sometimes opt to handle such errors differently. • In some cases, the script debugger may be invoked at the point of the error. • n still other cases, there may be no apparent indication that any error occurred because the host does not to notify the user. • Again, this is purely a function of how the host handles any errors that occur.

17. On Error Statements • Within any particular procedure, an error is not necessarily fatal as long as error-handling is enabled somewhere along the call stack. • If local error-handling is not enabled in a procedure and an error occurs, control is passed back through the call stack until a procedure with error-handling enabled is found and the error is handled at that point. • If no procedure in the call stack is found to have error-handling enabled, an error message is displayed at that point and execution stops or the host handles the error as appropriate.

18. On Error Resume Next • uses execution to continue with the statement immediately following the statement that caused the run-time error, or with the statement immediately following the most recent call out of the procedure containing the On Error Resume Next statement. • his allows execution to continue despite a run-time error. • You can then build the error-handling routine inline within the procedure. • An On Error Resume Next statement becomes inactive when another procedure is called, so you should execute an On Error Resume Next statement in each called routine if you want inline error handling within that routine.

19. On Error Resume Next • hen a procedure is exited, the error-handling capability reverts to whatever error-handling was in place before entering the exited procedure. • Use On Error GoTo 0 to disable error handling if you have previously enabled it using On Error Resume Next.

20. On Error Resume Next • hen a procedure is exited, the error-handling capability reverts to whatever error-handling was in place before entering the exited procedure. • Use On Error GoTo 0 to disable error handling if you have previously enabled it using On Error Resume Next.

21. On Error Resume NextPros and Cons • Episode of the Simpsons (Notes) • Problem: On Error Resume Next doesn’t actually fix the problem, it merely removes it from view. • On Error Resume Next is no miracle cure for scripting. • When you start a script, assuming there are no syntax errors that would cause the script to crash before it ever gets going, WSH tries to run the first line of code. • If the line runs successfully, WSH then tries to run the second line of code. • This process continues until each line of code has been executed. • At that point, the script automatically terminates.

22. On Error Resume NextPros and Cons • But what if WSH encounters a line of code that it can’t run successfully? Without On Error Resume Next, the script would come to a crashing halt, the script process would end, and an error message would be displayed. • If you’ve included On Error Resume Next, however, the script typically won’t blow up; instead, WSH will simply skip the line it can’t run and try running the next line. • 100-line script sample. • There’s definitely value in having a script that can recover from errors, especially when that script is being used by other people.

23. On Error Resume NextWhy? When? How? • We have here a simple code : • Notice the mistake we made in line 3: instead of typing b = 2, we typed b 2: On Error Resume Next Dim a a = 1 b 2 MsgBox a+b • The answer you will get is 1 • we’ve managed to turn our fancy new computer into a machine that can’t even add 2 and 1!

24. On Error Resume NextWhy? When? How? • B 2 is not a valid statement, and when WSH encounters this line an error occurs. • However, On Error Resume Next suppresses this error. • WSH then attempts to run the next line of code, something which, in this case, leads to problems. • Because of that, B is not assigned the value 2. • And because no value has been assigned to B, it automatically assumes the value of 0.

25. On Error Resume NextWhy? When? How? • Because you know that this answer is wrong (I hope) and because this script is so short, you probably know that the script needs debugging • In this case, then, debugging the script is easy. • But suppose this script was several hundred lines long, and suppose this was a much more complicated mathematical equation. • In that case, you might not know that the answer was wrong; even if you did, you might have trouble tracking down the problem.

26. On Error Resume NextWhy? When? How? • Running now tge script again will cause the follow message to be displayed • This time there’s no question about whether the script worked or not, and we don’t have to puzzle over whether 2 + 1 actually does equal 1. We know for sure that we have problems.

27. On Error Resume NextWhy? When? How? • Often in larger scripts we move to step 2 • There are two things we need to do here. • First, read the error message. • Second, pay attention to the line number reported in the error message. • Step 3 figure out the problem based on the error message, one thing you can do is look up the error code (800A000D) at the Microsoft Support site or VBScript documenatation, don’t forget that the value is hexadecimal so convert only the last 4 digits (000D) to a decimal number (13) • For this Error in the VBScript documentation you will get “Type Mismatch”

28. On Error Resume NextWhy? When? How? • For larger scripts is recommended to implement the following routines • Break your script into sections and test each section separately. Make sure each individual section is working before you re-test the script as a whole. • Implement a Trace Routine using msgboxes, acommand-line tool or displaying messages to the screen.

29. On Error Resume NextWhy? When? How? • Step 1: Get Rid of On Error Resume Next • whenever you are working on a script and whenever you suspect something has gone wrong, your first step should always be to remove or remark On Error Resume Next. • A better moral might be this: On Error Resume Next should typically be the last thing you add to a script, not the first thing.

30. Err Object • Contains information about run-time errors. • The Errobject is an intrinsic object with global scope — there is no need to create an instance of it in your code. • The properties of the Err object are set by the generator of an error — Visual Basic, an Automation object, or the VBScript programmer. • The default property of the Errobject is Number. • Err.Number contains an integer and can be used by an Automation object to return an SCODE.

31. Err Object • When a run-time error occurs, the properties of the Err object are filled with information that uniquely identifies the error and information that can be used to handle it. • To generate a run-time error in your code, use the Raisemethod. • The Err object's properties are reset to zero or zero-length strings ("") after an OnErrorResumeNext statement. • The Clear method can be used to explicitly reset Err.

32. Err Object Properties and Methods Number Property • object.Number [= errornumber] • Returns or sets a numeric value specifying an error. • Numberis the Err object's default property. • When returning a user-defined error from an Automation object, set Err.Number by adding the number you selected as an error code to the constant vbObjectError.

33. Err Object Properties and MethodsDescription Property • object.Description [= stringexpression] • Returns or sets a descriptive string associated with an error. • The Description property consists of a short description of the error. • Use this property to alert the user to an error that you can't or don't want to handle. • When generating a user-defined error, assign a short description of your error to this property. • If Description isn't filled in, and the value of Number corresponds to a VBScript run-time error, the descriptive string associated with the error is returned.

34. Err Object Properties and MethodsSource Property • object.Source [= stringexpression] • Returns or sets the name of the object or application that originally generated the error. • The Source property specifies a string expression that is usually the class name or programmatic ID of the object that caused the error. • Use Source to provide your users with information when your code is unable to handle an error generated in an accessed object. • For example, if you access Microsoft Excel and it generates a Division by zero error, Microsoft Excel sets Err.Number to its error code for that error and sets Source to Excel.Application.

35. Err Object Properties and MethodsSource Property • Source always contains the name of the object that originally generated the error. • your code can try to handle the error according to the error documentation of the object you accessed. • If your error handler fails, you can use the Err object information to describe the error to your user, using Source and the other Err to inform the user which object originally caused the error, its description of the error, and so forth.

36. Err Object Properties and MethodsHelp File Property • object.HelpFile [= contextID] • Sets or returns a fully qualified path to a Help File. • The contextID is a fully qualified path to the Help file. • If a Help file is specified in HelpFile, it is automatically called when the user clicks the Help button (or presses the F1 key) in the error message dialog box. • If the HelpContext property contains a valid context ID for the specified file, that topic is automatically displayed. • If no HelpFile is specified, the VBScript Help file is displayed.

37. Err Object Properties and MethodsHelp Context Property • object.HelpContext [= contextID] • Sets or returns a context ID for a topic in a Help File. • The contextID is a valid identifier for a Help topic within the Help file. • If a Help file is specified in HelpFile, the HelpContext property is used to automatically display the Help topic identified. • If both HelpFile and HelpContext are empty, the value of the Number property is checked. • If it corresponds to a VBScript run-time error value, then the VBScript Help context ID for the error is used. • If the Number property doesn't correspond to a VBScript error, the contents screen for the VBScript Help file is displayed.

38. Err Object Properties and MethodsClear Method • object.Clear • Clears all property settings of the Err object. • Use Clear to explicitly clear the Err object after an error has been handled. • This is necessary, for example, when you use deferred error handling with On Error Resume Next. • VBScript calls the Clear method automatically whenever any of the following statements is executed: • On Error Resume Next • Exit Sub • Exit Function

39. Err Object Properties and MethodsRaise Method • object.Raise(number, source, description, helpfile, helpcontext) • Generates a run-time error. • All the arguments are optional except number. • If you use Raise, however, without specifying some arguments, and the property settings of the Err object contain values that have not been cleared, those values become the values for your error. • When setting the number property to your own error code in an Automation object, you add your error code number to the constant vbObjectError. • For example, to generate the error number 1050, assign vbObjectError + 1050 to the number property.

40. What’s Next? • Regulars Expressions. • Methods and properties. • How to use the object and the object collections. • How to create complex patterns.