Par2: ErrorCode After Fetch() 2007-05-13 -- Scott Ripley The standard error functions (errorcode() etc.) are ONLY valid if the error returned is Level:Notify! If you will notice the first line of the TryFetch() method it calls Self.UseFile. If the return code is Level:Fatal from Fetch() or TryFetch() then you CAN NOT rely on errorcode() (etc.) because (sigh... follow closely...) TryFetch calls UseFile which can call OpenServer which can call OpenFile which can call AnError (ROUTINE) which can call Throw (filemanagers) which calls self.errors.takeerror() which calls (now in the errorclass) StoreErrorEntry which calls GetErrorEntry which calls SetID which (FINALLY!) does a GET on a queue which overwrites any previous value that could have been returned by errorcode() (etc.) after the attempted file open. ... phew! The bottom line is, if Level:Notify use the clarion errorcode() (etc.) functions, if Level:Fatal, use the GlobalErrors.GetErrorCode() My soap box is the following: The errorclass lets you get the errorcodes thru GlobalErrors.GetErrorCode() and will let you get the clarion or file errorcode but it falls way short of being able to provide the kind of information that the Throw methods display on the screen. Specifically, all the following fields ! %File -> FileName ! %Key -> KeyName ! %Error -> ERROR() string ! %ErrorCode -> ERRORCODE() ! %FileError -> FILEERROR() ! %FileErrorCode -> FILEERRORCODE() ! %Message -> User define message ! %Field -> Fieldname ! %ErrorText -> %FileError(%FileErrorCode) ! %Previous -> Whatever the previous incarnation of this error said ! %Procedure -> Current procedure name ! %Category -> The category of the error I have a process that MUST run silent and it would nice to have access to all of these just like the ErrorClass.SubsString method does so that my error logging could be more thorough. Printed November 21, 2024, 11:50 am This article has been viewed/printed 35237 times. |