Geting runtime error message

ohkovar

Member
Licensed User
I have an error label at the beginning of a function. Occasionally I get runtime errors and they get "hidden" by the my message in the error label block. I end up removing the error label to see what the actual error is. I don't want the user to see the actual error, but I would like to log it to a file.

Is there a way that I can grab the actual runtime error message, log it, then generate a msgbox to give the user a generic error?
 

ohkovar

Member
Licensed User
actually I am. I don't know how to get the original error message that caused the jump to the error label block.

Right now I am doing the following:

------------------------------------------------------
ErrorLabel(ComException)
.
.
.
Some Code
.
.
.
ComException:
ex.ThrowNew("Communication failed")
------------------------------------------------------
 

agraham

Expert
Licensed User
Longtime User
Haven't you looked at the demo for the library and read the help, it's all in there! :confused:

You need to get the actual exception - ex is an Exception object.
B4X:
ex.ControlRef =  B4PObject(6) ' get the exception details
Then you can use

B4X:
errortype = ex.Name  ' the name of the type of exception
errormsg = ex.Message ' the user message associated with the exception
 

ohkovar

Member
Licensed User
I have looked at the demo code. I was under the impression that the only data inside the exception object was what I put in. So the exception object will get automatically loaded with exception data by Basic4PPC without my interaction until I throw a new exception?
 

agraham

Expert
Licensed User
Longtime User
So the exception object will get automatically loaded with exception data by Basic4PPC without my interaction until I throw a new exception?
No! If you look in the demo each "catch block" of code at the end of each Sub loads the Exception object with the error object that Basic4ppc returns with B4PObject(6). You can then inspect it and decide what you want to do. The demo just displays the details to the user.
 

ohkovar

Member
Licensed User
I think I got it. I guess I could do the following, right?

--------------------------------------------------------------
ErrorLabel(xferDataComError)
.
.
Some Code
.
.

xferDataComError:

ex.ControlRef = B4PObject(6) ' get the exception details
msg = msg & " Name : " & ex.Name & CRLF
msg = msg & " FullName : " & ex.FullName & CRLF
msg = msg & " Message : " & ex.Message & CRLF
msg = msg & " InnerFullName : " & ex.InnerFullName & CRLF
msg = msg & " InnerMessage : " & ex.InnerMessage & CRLF
msg = msg & " Stacktrace : " & ex.StackTrace

logError(msg, False)

sync.result = kSyncStatusBad
'-----------------------------------------------------------
' Set the exception and give it a meaningful message
'-----------------------------------------------------------
ex.ThrowNew("Communication Error")
 

agraham

Expert
Licensed User
Longtime User
'-----------------------------------------------------------
' Set the exception and give it a meaningful message
'-----------------------------------------------------------
ex.ThrowNew("Communication Error")
Fine up to here but why do you want to rethrow the exception? You have logged it and set sync.result (whatever a sync is) to indicate an error. Don't you need to just leave it at that?

Rethrowing an error from within the catch block without further precautions as your code does will cause problems. From the help Overview
If a further exception occurs in the exception handling code without that code having executed any Errorlabel statements the behaviour of the optimised compiler is different to that of the IDE and legacy compiler. An exception occurring within exception handling code in an optimised compiled program will cause an unhandled exception to occur and a message box shown to the user as previously described. In the IDE and a legacy compiled program the exception handling code will be re-entered at its' original entry point, so potentially causing an endless loop.
 

ohkovar

Member
Licensed User
Well, this function actually uploads data, the calling method will call it again to upload another file. What has happened in the past is that some files will be uploaded and others will not (when an error occurs). The new exception allows the calling function to stop all attempts to upload files and notify the user that the "sync" failed.

I don't want my users seeing a message that will confuse them any more than they already are. That's why I am not including it in the new exception. I am using another error label in the calling function to stop all the file uploads.

Clear as mud?
 

agraham

Expert
Licensed User
Longtime User
The new exception allows the calling function to stop all attempts to upload files and notify the user that the "sync" failed.
I am afraid it won't. Exceptions in Basic4ppc (but not .NET) are always local to the Sub in which they occur. The exception will not propagate back to the caller of the Sub where the exception was raised but will re-enter the catch block of the same Sub. You will have to check sync.Result in your calling Sub or set ex.Clear before calling it and check ex.Saved after.

Again from the help
Clear : Clears the saved exception within the Exception object. As exceptions are entirely handled within the Sub where they occur the presence of an exception in an Exception object will show that an error has occurred in one or more Subs called by a Sub. This may help in signalling the occurrence of errors back down the call chain of Subs.
 

ohkovar

Member
Licensed User
but my exception "ex" is a global variable (as seen in the demo code and help). It seems to work the way I have it. When an error occurs, the uploads stop.

The calling function has an errorlabel set prior to calling this function and after the call returns, I check that ex.Saved = TRUE and then I rethrow. This will get the exception into the errorlabel block of the calling function (per the demo code and help).

The whole reason for this thread was to see if I could get the original B4PPC error.
 

agraham

Expert
Licensed User
Longtime User
The trouble with posting code fragments is that you don't give the whole picture of the structure you are working with.

I am afraid that I still don't understand how you are using ex.Rethrow as your code fragment positions it after the destination label for an exception and normally using it in that position either raises an error message box or causes a loop back to the error label depending upon which environment you are working in. However if it works for you then fine!
 

ohkovar

Member
Licensed User
agraham,

I didn't intend for my last message to sound harsh. If it did, I apologize. I REALLY appreciate you taking the time to help me. It's just hard to describe some logic in words and I wouldn't want to paste a bunch of code that may or may not help.

I believe I have the exception handling working per suggestions in the demo code..specifically the ErrorInCalledSub() routine. That is what I used as a model.

Thanks again for your help and quick turnaround to my posts.
 
Top