“Pseudo” Default VBA Error handling
The Glorious State of Transylvania
The first, possibly most fundamental Error handler,
On Error GoTo LabelOrLineNumber
Codes are in the next two posts, and in this post is some background theory and concepts needed.
“Pseudo” Default VBA Error handling (Taping / hooking on to lower level stuff)
Using code to mimic the default handler can possibly help in learning how to use VBA Error Handling.
A couple of tools we need to get started on this are:
_ some basic understanding of one of the Error Handling statements, On Error GoTo LabelOrLineNumber ;
_ and an available VBA object associated with the exception situation, Err
_ Sub Class a Windows Visual Basic Wonk aka mess with the Exception Software
I expect at the heart of error handling is the first of the main two error handling statements:
On Error GoTo LabelOrLineNumber
Windows and Visual Basic , like Excel and VBA are related things.
The default VBA Error Handling, like most pre determined things in Excel, can be mimicked by us as we have access to a lot of the stuff/software that it uses:
We might be loosely called “application ( Excel ) programmers”.
We, as application programmers, can access directly or indirectly a lot of the software used to create the application in the first place . ( A running or “open” Excel is often referred to as an application, or the Excel application. I suppose it is talking about the software being applied ).
We might say we are working at a higher level in the computing way of things, but in actual fact we can often get at more deeper stuff and tap off, hook into it, or hang bits of our coding into the chain of events that comprises more lower level programming.
Using code to mimic the default handler
What does On Error GoTo LabelOrLineNumber Statement organise and do ? :
As far as us end users are concerned, or as they experience it, this statement does as it suggests: it appears that once an exception is raised, the code continues. But it appears to do so in first being “sent” to the place of the LabelOrLineNumber, just as it would in any GoTo LabelOrLineNumber.
That is how it appears. But it is more subtle.
It does not simply “tell” VBA always to Go To the place indicated at every thing that causes an error:
The code is allowed to continue further from that place indicated, which is where it is “sent to” the first time that an error occurs. ****But a very important point to bear in mind when trying to understand VBA Error Handling in Runtime is that the exception in this situation is still raised. Effectively we have hooked onto, or embedded our code now into the Exception Software which has started due to the error occurring.
I think the way that it actually works is as follows: The code running, or execution is not really sent at any point to the place indicated.
Initially, Passing of the On Error GoTo LabelOrLineNumber code line has the effect of doing the following: It makes a copy of the code and hangs that on the predetermined chain of events that occur when an error occurs. The start of the copy of the code is not the original routine start, but the LabelOrLineNumber point.
A fun way of thinking about it could be to say we are transported to another World, say in The Glorious State of Exception in Transylvania. A copy of our coding is taken with us, and we continue running the coding from the place we were sent to.
In the Glorious State of Exception.
It is reasonable to expect that a code running in general in the exception state , (or being run now pseudo as part of the Exception software), is likely not to function completely as the same coding in the “normal” state would. In fact it appears that most things do actually work normally.
But one thing for sure doesn’t, and that is, possibly as might be reasonably expected, the following:
In the raised exception state, any ( further ) uses of the statements On Error GoTo LabelOrLineNumber or On Error Resume Next , ( be they other code lines or the original On Error GoTo LabelOrLineNumber such as in a looping code situation ) will be ignored. This is because the code is now part of what is sometimes referred to as a call back procedure. In simple terms the code can be thought of now as part of the Exception software code. The first use of the On Error GoTo LabelOrLineNumber effectively linked / transferred the code there, or started a copy of the code from that place, so further attempts to do that would be superfluous and so such code lines are ignored. In simple terms , once we are in the exception state then codes lines like On Error GoTo LabelOrLineNumber or On Error Resume Next are just past as if they were not there. (Not all the error “things”/ Statements wont work, that is to say do what they are supposed to in the Exception State, some will, but more to that later, …. ).
The two main error handling statements give a complicated set of instructions, and cause all sorts of internal things to go on, as do the other two statements contain a GoTo . The significance of the GoTo is god knows fucking what. I expect it was just done for fun, to confuse, but maybe I can come up later with some fun ways that make some abstract sense
_ Err Object.( Function..Ref.)
Err is a function that returns an ErrObject
This is a VBA object associated with the exception situation. It has a couple of methods ( .Clear and .Raise ) and a few Properties.
It does not usually directly control an error situation, or at least does not have that as its main purpose. ( It is sometimes used to see If an error occurred )
Err.Clear _ does not clear the exception. It simply empties some string variable properties containing information about the last error which occurred. In fun terms, think of it as not taking us back to the real world or place we were sent from.
It is mainly used to hold information about the last error. But it does have a Method which pseudo can be used to fool VBA into thinking that an error occurred, ( .Raise)
The Properties have mainly the purpose of storing information about the error that occurred. The Exception software usually passes information related to the error when the error occurs. ( When using .Raise you can additionally via the .Raise( , , , , , ) arguments effectively mess about with the coding which passes this information so as to fill the object with any relevant or irrelevant profanities of your choice)
I use the Err object in my next codes to get the same information that the Default VBA Error handling chucks up at me: We can use Properties of the Err object to get information about the error. I don’t use the .Raise here. ( I will look at that later – It appears to be a waste of time, and no one can remember quite much about it )
Very likely the Exception software uses this Err object in exactly the same way as I will to get its information, although it is a bit of a “Chicken and Egg” question / situation: The Exception software fills initially this object with text and number information about the error as it occurs and then uses this information itself in the message box pop up that comes up by default. At least that is my theory. No one seems to know for sure.
We can reference these Properties ourselves and retrieve them, like, for example, in a code line to get a simple description of the error that occurred , like this:
Dim TheErrorDescription As String
_ Let TheErrorDescription = Err.Description
Although the Exception software can fill the object with information, it appears that the information is , to at least a first approximation, held in a similar way that the properties of any typical VBA object such as a range might be. As such we can ourselves, with simple VBA code, assign them.
So as example, for the last example we could do this:
_ Let Err.Description = “Any Text I like”
The value that the exception software had given would then be replaced / overwritten.
I can do that at any time, but it would be overwritten if I did it before an error occurred.
( The same assigning could be achieved when using the .Raise to ““make” an imaginary error”, for example like:
Err.Raise(Number:=42 , Source:= , Description:= “Any Text I like” , HelpFile:= , HelpContext:= ) _ )
Codes to mimic VBA Default Error handling.
See next two posts
Ref
https://www.eileenslounge.com/viewto...247160#p247149
Reply With Quote
Bookmarks