Error handling 2.7 vs. 2.8

[Karl-Heinz]

Guys,

i got an rdd error and noticed that another ErrorDialog than mine shows the error now. Any ideas how my common Errordialog gets control of the exception again ? In the subclass i add a tab stop for better readability and i create my own log files. The name of such a log file depends on the name of the app.

Code: Select all

[STAThread];
FUNCTION Start() AS INT 
LOCAL oDlg AS ErrorDialogTab  // inherit Errordialog
LOCAL oXApp AS XApp

	TRY
		oXApp := XApp{}
		oXApp:Start() 
				  
	CATCH e AS Exception
		      
		oDlg := ErrorDialogTab { e }
		oDlg:showDialog() 
		
	END TRY
	
RETURN 0  

When i debug the mentioned rdd error i see that a voerror.log is expected in the XSharp.RT GAC dir ?

Code: Select all

System.IO.FileNotFoundException
Die Datei "C:WindowsMicrosoft.NetassemblyGAC_MSILXSharp.RTv4.0_2.6.0.0__ed555a0467764586VOERROR.LOG" konnte nicht gefunden werden.

Next debug step

Code: Select all

System.UnauthorizedAccessException
Der Zugriff auf den Pfad "C:WindowsMicrosoft.NetassemblyGAC_MSILXSharp.RTv4.0_2.6.0.0__ed555a0467764586VOERROR.LOG" wurde verweigert.

i added the XSharpPublic/Runtime/XSharp.RT/Functions/Error.prg sources to my app and now the VOERROR.LOG is created in the app folder. Seems the usage of the WorkDir() function inside the XSharp.RT dll is responsible for pointing to the XSharp.RT GAC dir ?

Code: Select all

INTERNAL FUNCTION __OpenErrorLog() AS IntPtr PASCAL

	LOCAL cFile                     AS STRING
	LOCAL cBuffer                   AS STRING
	LOCAL hfRet                     AS IntPtr

	cFile := WorkDir() + SetErrorLogFile() // <----------

ok, but my main problem is: i want the exception back :woohoo:

regards
Karl-Heinz

[robert]

Karl-Heinz,

I assume your project is using the VO Dialect, Is that correct ?

The reason why we had to add an error handler, was that certain (RDD related) functions in the runtime were throwing an error where they were expected to return FALSE to be compatible with VO. For example VoDbUseArea() for a file that is opened by another user/ process.
In the VO dialect we are now intializing ErrorBlock() with a call to DefError(). This function handles the sharing violation and locking violation errors.

Inside the DefError() code we are using a global delegate ShowErrorDialog_Handler with the following prototype:
DELEGATE ShowErrorDialog_Delegate(oError AS Error) AS INT

You can change this global (point it to an error handler of your choice) to show your own dialog.

And yes, the WorkDir() is indeed not correct here if we want to write the error log to the app folder. I'll change that for the next build.

Robert

[Chris]

Hi Karl-Heinz,

Oh, so that was where the voerror.log file was hiding in Robert's session, it was (trying to) being generated in the GAC folder! Thanks for pointing this out, will take care of it. I think the problem is with WorkDir() which gets the current path form the calling assembly folder, instead of the running assembly folder.

About the error dialog, how had you replaced the default one with yours? What changed in the last build, is that now there's a new GLOBAL in XSharp.RT, which holds a pointer to a function/method that displays the error window:

Code: Select all

DELEGATE ShowErrorDialog_Delegate(oError AS Error) AS INT
GLOBAL ShowErrorDialog_Handler AS ShowErrorDialog_Delegate

Then the default error handling function used by the default ErrorBlock uses this global to open the default error window dialog. If you have included a reference to XSharp.VO in your app, then this GLOBAL points to a function that displays a VO-like error window. If you haven't, then a generic windows message box is shown.

So, by NULLing this global, you can make the error handler use a generic window. By making it point to a function in your own code instead, you can call the default error function to actually call your code and decide what to do with it, show a custom dialog, or decide otherwise what to do with the error. This function needs to return one of the following integer values:

ES_WHOCARES := 0
ES_WARNING := 1
ES_ERROR := 2
ES_CATASTROPHIC := 3

[Chris]

Hi Karl-Heinz,

Ah, sorry, please forget what I said above, I now understand the problem. In previous builds, RDD errors where throwing exceptions, but that was incompatible with VO, which instead of that it is displaying an error dialog, with options to Ignore, Retry or Abort the app. In 2.8, a VO-compatible system is implemented, which means it does not let you handle exceptions directly. But there's an easy way to revert to the previous behavior, by using something like:

Code: Select all

ErrorBlock( { |error| DoThrow(error) } )

PROCEDURE DoThrow(oError AS Exception)
THROW oError

This uses a custom error block, which instead of opening the default VO-like error dialog, instead throws the exception back, for you to handle it directly in your code.

[Chris]

Oh well, we really need some kind of a

Code: Select all

BEGIN LOCK REPLYING TO <message>

command or similar