Access97 errors

[Jonathan Scott via AccessMonster.com]

In a certain function, I am trying to process data I expect to be a date.
But, as with all things, I have to prepare for the worst: the String given
to me does not translate into a date.

What is the natural progression? Raise an error/exception! But wait, I can
pass an error to myself, but I cannot tell my caller that I have received
invalid data, through an error/exception?!

Please tell me I am wrong. "Err.raise" is not a pseudonym for "goto", right?
How can I tell my caller that he/she has given me invalid data to process?

Jonathan Scott

 

[tina]

well, i'm using A2000, not A97, but suggest you see if the IsDate() function
is available in VBA in A97. if so, you can test the returned string to see
if it is a date, and run your code accordingly. something like

If IsDate("my data") Then
'run your code here
Else
Msgbox "You didn't provide a valid date."
End If

see the IsDate Function topic in VBA Help for details.

hth

 

[Jonathan Scott via AccessMonster.com]

Thanks for responding.

Yes, that is exactly what I am doing. And when I see it is not a date, I
want to tell the calling procedure that he/she needs to do something about
it.

I still need a way to tell my caller that they need to take extraordinary
action; not a goto statement.

Jonathan Scott

 

[tina]

okay, i don't think i quite got what you meant before. if i understand
correctly now, you're running procedure A, and in it you're calling
procedure B to evaluate a certain value as a valid date. to pass the result
of the evaluation back to the calling procedure, i usually do something like
this:

Private Function MyCalledProcedure() As Boolean
'if necessary, this can be a public function, of course.

If IsDate("my data") Then
MyCalledProcedure = True
Else
MyCalledProcedure = False
End If

End Function

Private Sub MyCallingProcedure()

If MyCalledProcedure Then
'run your code here
Else
Msgbox "You didn't provide a valid date."
End If

End Sub

if i'm still not getting your point, then post your calling procedure, and
your called procedure, with comments.

hth

 

[Jonathan Scott via AccessMonster.com]

The point of the procedure is not to validate. I am passing in some fields
to a function which is supposed to then give me back a part of a WHERE
clause. Each call gives only a part of it. If any one of those calls fails,
I want the whole string to be invalid. This is not ordinary execution, and
one huge procedure to do all of this would be unwieldy.

I think the concept of exceptions/errors is not very mature in Access.
Errors act like a complicated goto statement. If you want to cause an
error, you have to catch it yourself. Doesn't make for very good inter-
object communication.

Thanks for your help, but I will not post code now. It would be a waste of
time, it seems to me.

Jonathan Scott

 

[tina]

sorry i wasn't more help. you can probably do what you're trying to do, but
either we're suffering a mutual lack of communication, or i'm not
sufficiently skilled in VBA to give you the solution you need. suggest you
start a new thread, probably in the access.modulesdaovba newsgroup - with
the final explanation you gave here (so you're not starting over from
scratch). there are a number of expert Access/VBA users in these newsgroups
who will likely be able to help you. good luck.

 

[Marshall Barton]

In a certain function, I am trying to process data I expect to be a date.
But, as with all things, I have to prepare for the worst: the String given
to me does not translate into a date.

What is the natural progression? Raise an error/exception! But wait, I can
pass an error to myself, but I cannot tell my caller that I have received
invalid data, through an error/exception?!

Please tell me I am wrong. "Err.raise" is not a pseudonym for "goto", right?
How can I tell my caller that he/she has given me invalid data to process?

Err.Raise is defintely not a GoTo.

If I understand you're trying to do here, it sounds like
it's exactly what you want to use.

Err.Raise xxx in your function will raise error number xxx
in the calling procedure. The calling procedure would
handle it the same way it would handle any other error.