Nesting error at runtime?

[Olaf Doschke]

The strangest things happen lately:

I get error 96 (Nesting error) ereported in a certain inherited method, but in no particular line number (lineno() is 0)
This seems very weird to me, as a nesting error would stop the compilation at build time and would never be able to happen at runtime. The only way a nesting error could be expected at runtime is due to Execsript(), which is not in play here. Even macro substitution cannot cause it, as you can't substitute anything needing multi line code to be nested at all.

So the master question is: In what circumstances could a nesting error occur?

One detail: The method in question is called PreSaveHook and called from the save method of a data access class:

If Not This.PreSaveHook()
   *--- If presave conditions fail, cancel save
   Return CANCEL
Endif

This is the lowest nesting level of the save method, so no nesting can be broken on this level, too. One further mentionable thing is, that data access objects may be "stacked", in that a parent object starts a transaction and trigger child objects save, after itself successfully saved.

At least it's not urgent, because it wasn't reproducable, but it would good to know how to get at the source of a nesting error, if one happens. ASTACKINFO is on my list, I thought it's already used in the general error handler, but no stack info is reported in the error screenshot. Line 0 is something I normally only get, if a database trigger fails, but in this case the backend is MS SQL Server, not a DBF of a DBC.

Could a network error cause some object to fail and cause a nesting error?

Bye, Olaf.

 

[Mike Lewis]

Olaf,

The only time I remember seeing the LINENO() returning 0 is when running in an executable for which Debug Info is not selected (or maybe it was an encrypted exe?). Could that be the case here?

By the way, what is CANCEL? Is it a variable? or a defined constant? I wonder if the fact that it is a key word might be confusing things. Probably not, but you never can tell.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>Debug Info is not selected
That's the case, yes.

>what is CANCEL? Is it a variable? or a defined constant?
It is a constant. In fact it's called FILE_CANCEL, but I didn't want to confuse you with details on why it's called FILE_CANCEL instead of simply cancel. In fact you give a good reason, but it has nothing to do with a file, neiterh DBF nor any other file, it's cancelling save to a remote database. Historically it may have been called that way because it was first done for DBFs. Anyway a good point.

Bye, Olaf.

 

[GriffMG]

I would code it like this and see if it makes a difference:

Private RetVal
RetVal = CONTINUE
If Not This.PreSaveHook()
   *--- If presave conditions fail, cancel save
   RetVal = CANCEL
Endif 
Return(RetVal)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

Thanks Griff,

misundertood. The error is happening inside the PreSaveHook. Too much code to post here (and too confidential). I just posted the calling code to show there is no nesting error to be expected on this level, the level of calling.

But indeed, what is a currently unpaired until the PreSaveHook finishes is the IF/ENDIF. But is ENDIF really a command "executed" and one ENDIF too much would cause a nesting error? It would perhaps help to formulate the call as:

LOCAL lnRetVal, llSuccess
lnRetVal = OK
llSuccess = This.PreSaveHook()
If NOT m.llSuccess
   lnRetVal = CANCEL
Endif 
Return m.lnRetVal

Then there really is nothing nested during the PreSaveHook call or while RETURNing. That's of course always a good concept. I know RETURN from WITH/ENDWITH is not recommendable, but that has reasons in the (virtual) object active during that block. There is nothing comparable in an IF/ENDIF block. OF course another block with it's own rule is the CATCH block of TRY...ENDTRY.

In the end the question is more about general reasons for a nesting error at runteime, not so much about the given code.

Bye, Olaf.

 

[GriffMG]

I really don't think it matters, but as you had a nesting error - I thought it might help.

Most people seem to code their returns willy nilly, I just like to have one.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[mjcmkrsr]

Hi Olaf

From VFP Help "Nesting Error - Error 96"

One of these situations has been encountered:

A DO is present without a matching ENDDO or vice versa

A SCAN is present without a matching ENDSCAN or vice versa

A FOR is present without a matching ENDFOR or vice versa

A LOOP or EXIT clause is present outside the DO WHILE ... ENDDO, FOR ... ENDFOR, or SCAN ... ENDSCAN commands.

hth

MarK

 

[NasibKalsi]

your question is deeper than the obvious. I could add few cents: hardware may have gotton hot and cause memory leak, especially if run on a laptop. returning from valid() could go in infinite loop, but this could only hangup the process. i think it is more like a hardware issue.

 

[Olaf Doschke]

Thanks, Mark, for pointing out the commands to look out for. IF is not mentioned, still can be nested, also transactions, but it's likely not the cause of error 96 and you're right I should concentrate on the list mentioned in the help chapter. Nevertheless none of those errors do compile to an executable, so they don't occur at runtime. That's the big mystery. Plus the help is wrong or incomplete in some places.

Nevertheless you show one way to trigger the Error 96 at runtime, by

lcMacro = "Exit"
&lcMacro

Put into a prg this compiles and causes the nesting error at runtime. Something similar to this might happen. That's actually a design flaw of macro substitution to be able to compile things which never will work. It's not always that obvious.

Nasib, I think you could also be on the right track. I still would like to be able to trap the cause in error handling, if this error happens again.

Bye, Olaf.

 

[Koen Piller]

Hi Olaf,

your quote
Plus the help is wrong or incomplete in some places
unquote

Francis has put a lot of efforts in correcting and rebuilding the help file see in CodePlex:

https://vfpx.codeplex.com/wikipage?title=VFP 9 SP2 Help File&referringTitle=Home

In case you still find errors or incompleteness would you be so kind as to report? I am sure he is most willing to produce an update.

Gruss,

Koen

 

[Koen Piller]

Hi Olaf,

Francis has meanwhile confirmed this will be corrected with the next update of the VFPHelpfile.

Gruss,

Jockey(2)

 

[Olaf Doschke]

Koen,

I still can't tell you what else would play a role, so not too fast with help changes. I will perhaps never see that error again. And I'll look into what else I remember and find having been discussed about help file incorrectness.

Bye, Olaf.