I'm doing a temp fix on an Excel-based system until I get
the .NET and connected version written. There is a
summarizer file that extracts data from a directory. I've
manually cleaned out non-compliant files. Now I want to
test for non-compliance in the VBA and perform some action
to correct the error (which works, btw).

The current flow has the "On Error GoTo BlahBlah" and when
I try to test and intercept the bad file to close and move
it, the error flag gets set to true and it goes to the
BlahBlah error code instead of performing my actions.

I've tried IsError, IsMissing, IsNull and the various
other IsProblem functions all of which return a TRUE which
exits the sub.

I don't want to rewrite all the error handlers for the 3
months it'll take to customize the new app. Any
suggestions for this VBA prob?

Thanks in advance,

E.

Hi,

I don't know that I quite understand what you are doing. The normal
structure of VBA error handling is:

Do While (somecondition)
On Error Goto BlahBlah
. . . code which may raise an error

ResumePoint:
. . . other code to continue processing (perhaps the next file in your
case)
Loop

Exit Sub

BlahBlah:
. . . Code to handle error conditions. Often like:
Select Case Err.Number
Case 1004:
. . . etc.

Resume ResumePoint: ' Having dealt with the error condition resume
processing.
End Sub

The key issue is the Resume statement in the error handler. That is the
stage that pushes you back into the "mainstream" of the program.

I hope this helps, but I'm not certain I fully understand your question :-(

Regards,

Peter Beach

"Esteban404" wrote in message
...
I'm doing a temp fix on an Excel-based system until I get
the .NET and connected version written. There is a
summarizer file that extracts data from a directory. I've
manually cleaned out non-compliant files. Now I want to
test for non-compliance in the VBA and perform some action
to correct the error (which works, btw).

The current flow has the "On Error GoTo BlahBlah" and when
I try to test and intercept the bad file to close and move
it, the error flag gets set to true and it goes to the
BlahBlah error code instead of performing my actions.

I've tried IsError, IsMissing, IsNull and the various
other IsProblem functions all of which return a TRUE which
exits the sub.

I don't want to rewrite all the error handlers for the 3
months it'll take to customize the new app. Any
suggestions for this VBA prob?

Thanks in advance,

E.

You are correct about the structure and that's what is
present. What is happening is that an additional error is
ocurring in a new environment and not being specifically
intercepted. I'm trying to test for that error, but my
error flag (in a called sub) is going back to the main
execution, not the current sub.

Sub 1()
on Error...
call Sub 2
exit sub
ErrorHandler
resume
End sub '1

Sub 2()
On Error...
test //this produces error state that goes back to Sub 1
exit sub
errorHandler_Sub2
//do something on main thread (resets global variable-1)
resume
end sub

The sheet is a spaghetti fest that I've reduced to 5 major
subroutines responsible for the major actions and tried to
remove loops external to a process if that's all they did
and they did it every time through w/minor testing. I
believe I'm going to have to code for specific errors and
try to capture this new one in the main thread rather than
allowing the calls. I have a thermos of coffee, so it's no
prob. I don't know why the other routines are there since
they are part of the main routine.

Thanks for the input.

E.

-----Original Message-----
Hi,

I don't know that I quite understand what you are doing.
The normal
structure of VBA error handling is:

Do While (somecondition)
On Error Goto BlahBlah
. . . code which may raise an error

ResumePoint:
. . . other code to continue processing (perhaps the
next file in your
case)
Loop

Exit Sub

BlahBlah:
. . . Code to handle error conditions. Often like:
Select Case Err.Number
Case 1004:
. . . etc.

Resume ResumePoint: ' Having dealt with the error
condition resume
processing.
End Sub

The key issue is the Resume statement in the error
handler. That is the
stage that pushes you back into the "mainstream" of the
program.

I hope this helps, but I'm not certain I fully understand
your question :-(

Regards,

Peter Beach

"Esteban404" wrote
in message
...
I'm doing a temp fix on an Excel-based system until I
get
the .NET and connected version written. There is a
summarizer file that extracts data from a directory.
I've
manually cleaned out non-compliant files. Now I want to
test for non-compliance in the VBA and perform some
action
to correct the error (which works, btw).

The current flow has the "On Error GoTo BlahBlah" and
when
I try to test and intercept the bad file to close and
move
it, the error flag gets set to true and it goes to the
BlahBlah error code instead of performing my actions.

I've tried IsError, IsMissing, IsNull and the various
other IsProblem functions all of which return a TRUE
which
exits the sub.

I don't want to rewrite all the error handlers for the 3
months it'll take to customize the new app. Any
suggestions for this VBA prob?

Thanks in advance,

E.


.

Hi,

Well the error raised in Sub2 should be handled in Sub2. If it's not then
something else is happening.

What I suggest you do is put breakpoints in both of the error handlers and a
breakpoint in Sub2 and you may be able to work out what is happening. I
wonder if your error handler in Sub2 isn't itself throwing an error - errors
in error handlers can be very troublesome :-(

Regards,

Peter Beach

"Esteban404" wrote in message
...
You are correct about the structure and that's what is
present. What is happening is that an additional error is
ocurring in a new environment and not being specifically
intercepted. I'm trying to test for that error, but my
error flag (in a called sub) is going back to the main
execution, not the current sub.

Sub 1()
on Error...
call Sub 2
exit sub
ErrorHandler
resume
End sub '1

Sub 2()
On Error...
test //this produces error state that goes back to Sub 1
exit sub
errorHandler_Sub2
//do something on main thread (resets global variable-1)
resume
end sub

The sheet is a spaghetti fest that I've reduced to 5 major
subroutines responsible for the major actions and tried to
remove loops external to a process if that's all they did
and they did it every time through w/minor testing. I
believe I'm going to have to code for specific errors and
try to capture this new one in the main thread rather than
allowing the calls. I have a thermos of coffee, so it's no
prob. I don't know why the other routines are there since
they are part of the main routine.

Thanks for the input.

E.

-----Original Message-----
Hi,

I don't know that I quite understand what you are doing.
The normal
structure of VBA error handling is:

Do While (somecondition)
On Error Goto BlahBlah
. . . code which may raise an error

ResumePoint:
. . . other code to continue processing (perhaps the
next file in your
case)
Loop

Exit Sub

BlahBlah:
. . . Code to handle error conditions. Often like:
Select Case Err.Number
Case 1004:
. . . etc.

Resume ResumePoint: ' Having dealt with the error
condition resume
processing.
End Sub

The key issue is the Resume statement in the error
handler. That is the
stage that pushes you back into the "mainstream" of the
program.

I hope this helps, but I'm not certain I fully understand
your question :-(

Regards,

Peter Beach

"Esteban404" wrote
in message
...
I'm doing a temp fix on an Excel-based system until I
get
the .NET and connected version written. There is a
summarizer file that extracts data from a directory.
I've
manually cleaned out non-compliant files. Now I want to
test for non-compliance in the VBA and perform some
action
to correct the error (which works, btw).

The current flow has the "On Error GoTo BlahBlah" and
when
I try to test and intercept the bad file to close and
move
it, the error flag gets set to true and it goes to the
BlahBlah error code instead of performing my actions.

I've tried IsError, IsMissing, IsNull and the various
other IsProblem functions all of which return a TRUE
which
exits the sub.

I don't want to rewrite all the error handlers for the 3
months it'll take to customize the new app. Any
suggestions for this VBA prob?

Thanks in advance,

E.


.

Thanks, Peter. I'll just bet your're right that the error
handlers are doing it. I'll add some breaks and some Err
nbrs and descriptions to see if they are firing even after
the code issues an Err.Clear action. That should be
conclusive. :-\

E


-----Original Message-----
Hi,

Well the error raised in Sub2 should be handled in Sub2.
If it's not then
something else is happening.

What I suggest you do is put breakpoints in both of the
error handlers and a
breakpoint in Sub2 and you may be able to work out what
is happening. I
wonder if your error handler in Sub2 isn't itself
throwing an error - errors
in error handlers can be very troublesome :-(