#198891 - 2010-06-22 03:47 PM
Avoiding premature Script exits on errors
|
AndreasBucher
Fresh Scripter
Registered: 2010-06-22
Posts: 13
Loc: Stuttgart, Germany
|
Hi,
I'm trying to start easy ... and this is not a code-specific issue, but some generic question about KIX.
My concern with kix is that it completely exits on any kind of errors - unlike other languages, that my rise an error, but still keep executing (both way may create trouble, I know ...).
Did a few searches thru this board and other resources, but couldn't find any useful hints - and may have used the wrong keywords for the search, because this topic is not easy to describe in search terms.
Please feel free to move it to a more apropriate forum, if necessary.
To be more specific:
Thelogin script I provide is organized as KIX scripts calling each other in sequence. Mainly, there is a central script defining all required vars and functions globally, and then calls the other sections one by one. One of those sections is related to all workstation items, like checking and installing things. Another one is good for doing user-related stufff, like drive mappings, etc. There are reginal sections delegated to other teams, and a option user login script.
So, the central part is called from the initial login.bat, and then everything stays in KIX until done, only then returning to the initial BAT. The BAT launches the KIX interpreter, which runs the CENTRAL section. This one then calls the WKST, USER, REGIONAL and other KIX sections (call and return for each), each in separate KIX files.
The trouble now starts when one of the KIX sections fails for any reason (programming error, data read error, etc.). Instead of returning to the calling KIX (e.g. CENTRAL section), the KIX interpreter "aborts" and returns to the calling batch - with the result that none of the remaining sections are executed ! Therefor, I can never make sure the later login script sections are executed if one of the earlier ones fails - plus, I have no clue where it failed. (in fact, I have, because I already do some extensive logging ... but that involves additional code and execution time)
I could work around that by using the classic approach, calling the KIX interpreter for each script section from the initial batch - but that involves loading KIX32.EXE each time, and not having global vars and functions available. That's why I scrapped that aproach (it was done like that before, but for other reasons), ad went for the direct KIX calls.
What I am searching for ist somtheing to prevent the KIX32.EXE to exit at each error, but maybe just exit the current level of execution, and return to the previous one. Is there anything to achieve this ?
Hopefully I made it clear what I was talking about.
Sorry for this rather "longish" text, but IMHO the topic requires some explanation.
Thanks your your help
Andreas
_________________________
King regards,
Andreas
|
|
Top
|
|
|
|
|
#198895 - 2010-06-22 05:49 PM
Re: Avoiding premature Script exits on errors
[Re: AndreasBucher]
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
The simple answer is no, you cannot trap a code error.
Most interpreted languages will abend if you mangle things badly enough. KiXtart is very forgiving, but if (for example) you try to reference an invalid array element, or divide by zero then it will stop.
KiXtart is pretty hard to break if you code for exceptions and check data instead of just assuming that it's OK.
Objects are the one thing that can really bite you - you don't have any control over how they react so they can halt the script before you get a chance to manage any exception.
One method I use when I want to sandbox a child script but still share variables is:
- Parent creates a script contaning the variables in a new file in $FOO="bar" format.
- Parent executes the child script in a new instance of KiXtart.
- Child CALLs the variable script to load the variables.
- Child executes.
- Child re-writes the variable script file using the updated variables.
- Child write it's state to the variable script file and exits
- Parent CALLs the variable script file to load the updated variables and checks the child finish state, raising an alert if the child failed.
Objects are you only problem here again, as you can't store the instance in a text file in any simple way.
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
1 registered
(Allen)
and 781 anonymous users online.
|
|
|
