DB Errors in a Dta/DtaDlg window

[Karl-Heinz]

Hi Chris,

some months ago you gave the advice to add the Method Error ( e ) to catch DB Errors within a Dta / DtaDlg window. That works, but why does e:StackTrace show NIL instead of the method/Line that caused the error ?

If a server is used in a Dlg window the exception goes to my common Handler where e:StackTrace shows which Method/Line caused the DB error.

regards
Karl-Heinz

[wriedmann]

Hi Karl-Heinz,
I'm not Chris, but I think to know the answer: in .NET the exe /dll does not contains any line information.
You need to have compiled with debug and to have the .pdb file near to the executable.
This is why I'm delivering always both exe/dll and pdb.
Wolfgang

[Karl-Heinz]

Hi Karl-Heinz,
I'm not Chris, but I think to know the answer: in .NET the exe /dll does not contains any line information.
You need to have compiled with debug and to have the .pdb file near to the executable.
This is why I'm delivering always both exe/dll and pdb.
Wolfgang

yes, i´m aware about this, but that is IMO in this case not the problem.

The attached image contains 3 exception hard copies, thrown by Dlgwindow and DtaWindow code. Note: Both windows are in the same app. The first HC shows the Dialog Exception catched by a handler installed at startup. As you see the line that caused the DlgWIn exception is shown in the first HC, while the other HCs do not show the line that caused the error.The HCs two and three are based on this DtaWin code.

Code: Select all

METHOD Error (e) CLASS DtaWin

	// Stacktrace shows NIL 	
	
	msginfo( e:ToString()  + crlf  + ;
		AsString ( e:StackTrace ) , "DtaWin - Callback Method Error() triggered" ) 
    
	// trying to forward the exception to the global exception handler		
	
    e:THROW()   
	
	RETURN SELF  

Maybe i miss something special, if the Method Error (e) is triggered ?

regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

I do not remember a discussion about this, maybe it was Robert who suggested this? Do you have a repro sample showing this behavior?

[Karl-Heinz]

Hi Karl-Heinz,

I do not remember a discussion about this, maybe it was Robert who suggested this? Do you have a repro sample showing this behavior?

Nope, it´s been you.

i´ll send you tomorrow a viaef. At the moment it ´s much too hot ... seems the earth has moved these days and i´m living in Greece now

regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

Nah, it's cold here, we are only at 29C right now at 9 at night

No, seriously, my brain is burnt from the heat of the summer, can you please send me a link to our previous discussion about this to refresh my memory?

[Karl-Heinz]

Here´s a part of your email from Fr 18.01.2019 21:53


Hi Karl-Heinz,

[...]

there's a BEGIN SEQUENCE in the DBServer FieldPut() method, which eats the exception. But it does report the error, if you define a method in your DataDialog:

METHOD Error(oError)
? "error intercepted, see oError object for details"
RETURN NIL

[...]

Strange is that this is needed for Dta /DtaDlg windows, while in a Dialogwindow such an exception goes directly to a common exception handler. On the other side:That´s excately how VO behaves: VO throws an error if the server is used in a Dialogwindow,but not if the server is used in a Dta/DtaDlg .My guess was that the reason might be because a DialogWIndow doesn´t have a a FormDialog surface like a Dta/DtaDlg has, so the error never reaches the real surface ?

regards
Karl-Heinz

[Chris]

Hi Karl-Heinz,

Thanks, I remember now! Yeah, probably it's what you say, in one type of window the message gets lost somewhere. You can see how this works in the SDK in VO, in the DBServer class Error() method, the message is sent to all elements of the "aClients" array. So maybe it's only than in some window types do not register themselves to this array.

About the callstack being empty, I see what is happening, it's because of the way the Error object is created, based on the original exception that occured. If you look at Error class in the XSharp.Core source code in Git, in the constructor at line 132 a new Error object is being constructed and gets the properties copied from the original Exception object. But "StackTrace" is a read only property, so its contents cannot be copied to the new object. Maybe we will need to rethink this approach, will have a further look into it.

[Karl-Heinz]

Hi Chris,

Thanks for looking at it. Do you still need a sample ?

regards
Karl-Heinz

[Chris]

No thanks, I see the problem directly in the code!