Keisuke,
> isn't "Method called on error" executed in the same process as the
> invoking method?
>
> normally the code would only be interested in basic information such as OK,
> which changes the course of action (ignore, abort, retry).
>
> even if more details were available,
> there is normally not much one can do on the spot.
>
yes it probably is. However, I am not interested in what method is
currently set to be invoked by On Err Call, I am interested in
returning information FROM the method invoked by On Err Call -
specifically - what error occurred.
So, in the below 2 lines of code I want to get information FROM
'File_Error_Manager' detailing, as much as possible, what error(s)
occurred.
ON Err Call("File_Error_Manager")
Open Document($Document)
The On error call method (File_Error_Manager) has something like this:
Case of
: (error=-54) | (error=-49) | (error=-46) | (error=-45) | (error=-44) |
(error=-5000)
<>x_Error_Call_Error:="File, folder or volume locked, or already open
for writing."
.
.
.
end case
As far as I am aware, when On Err Call invokes a method it runs in it's
own process - separate from the process where the error actually
occurred. Given this situation, there are limited ways in which to
communicate the error information from the On Error Call process to the
error generating process. IP variables are a simple means of doing
this.
The use of IP variables in an error method used by On Err Call and any
process which, thru On Err Call usage, uses these error methods
becomes - thread unsafe.
Because of the way in which 4D manages file/disk access the only way to
know that there was an error, and to get details of that/those errors,
is to use On Err Call.
Using LEP (for file manipulation) by passes this issue, as there is no
need for On Err Call.
As I said, there are other reasons to use LEP for file manipulation,
Thread safety is just one that I thought would be of interest to
discuss. Speed is another, my experience so far, is that 4D's file
manipulation functions are slower then the OS level functions.
As for alternate means of getting error information out of On Err Call,
the only one that comes to mind would be to create a record in an
'Error' table. Populate it with the error information, some sort of
identifier (this might be an issue), and save it.
Then in the process where an error *might* occur, query the table to
determine *if* there was an error, and if there was, get the
information from the record (and do whatever is appropriate), and
delete the record.
Seems excessive, but I guess that would depend on how necessary it
is/was to make a method thread safe.
Other means of getting error information out of the On Err Call
process, and back to the error generating process are welcome.
:)
>
> "Method called on error" can log (table or document) the date, time,
> user, machine,
> error stack, error method, error formula, error line for later analysis.
>
there is no indication that this is true according to the documentation
for v13. Maybe the function has been enhanced in later versions of 4D.
However, even if this is true, the need is to get error information
during runtime to manage it.
In the above example, to know that the file was not able to be opened.
Which in turn means that the action intended can not be done/completed,
and make a decision about how to proceed. That decision maybe made in
the same method in which the error occurred, or it may be passed back
up the call chain; being able to analyze the issue later is not the
intension/need.
Thanks
Chip
---------------
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
