Spy00000, а что касается версии для vbs, достаточно ли просто сделать аналогичную вставку "On Error Goto 0" до "WScript.Quit" для корректной работы?

Я думаю - да, НО я на VBS почти не пишу, в основном готовые куски кода в WSH вставляю, чтобы на JS не переписывать. Так что могу ошибаться.

У меня два вопроса.

1. Может быть стоит подумать в сторону Run, Exec внешних скриптов? Тогда не надо будет ломать голову над тем как безболезненно выйти из дочернего процесса при этом сохранив работоспособность родительского. А эту тему и код, написанный по случаю использовать для других нужд.?

2. По теме наваял эдакий класс, который суть обертка вокруг вызова методов ScriptControl. Фактически, ООП-вариация первоначального кода коллеги JSman. Делиться?

Начну со второго вопроса.
2. Если есть в нем какой-то определенный смысл, то, конечно, делитесь. Я думаю, что это здравая идея представить это отдельным классом. Но может быть до использования класса еще подумаем над корректной поддержкой работы методов WScript (ConnectObject, CreateObject и др.), для того чтобы не пришлось сильно коверкать его структуру в процессе разработки?

1. Что касается первого вопроса, то буду рад услышать Ваши мысли вот в этой теме.

1. Может быть стоит подумать в сторону Run, Exec внешних скриптов? Тогда не надо будет ломать голову над тем как безболезненно выйти из дочернего процесса при этом сохранив работоспособность родительского. А эту тему и код, написанный по случаю использовать для других нужд.?

2. По теме наваял эдакий класс, который суть обертка вокруг вызова методов ScriptControl. Фактически, ООП-вариация первоначального кода коллеги JSman. Делиться?

2) если язык используется JS, то написать паттерны, позволяющие осуществить выход из кода в нужно точке. Пример такого паттерна:

(function(){
MY-CODE
}).call(this);

Выход реализуется ключевым словом return.

Только если код будет вида

(function(){
...
  function MyFunc(){
    ...
    WScript.Quit();
    ...
  }
...
}).call(this);

замена "WScript.Quit();" на "return;" приведёт к выходу только из внутренней функции.

Коллеги, может быть мне стоит создать отдельную тему с полным описанием?

Отчего нет?!

Насколько удаленный сервер безопасен? Известно, что нельзя доверять данным, пришедшим извне, тем более по широкодоступным средствам связи.

В настоящий момент пока это неважно. Сервер управляется мной, доступ к нему имею только я.

Возможно Вы правы, исключения можно предусмотреть в коде и логировать их с последующей отправкой на сервер.

Окей, получается, что предварительно, перед использованием, код необходимо
1) проверить на наличие объекта WScript (исключением является WScript.Sleep()),
2) если язык используется JS, то написать паттерны, позволяющие осуществить выход из кода в нужно точке. Пример такого паттерна:

(function(){
MY-CODE
}).call(this);

Выход реализуется ключевым словом return.

А стоит ли включать в код заранее подготовленные функции типа Download(Url, Destination), Run(Cmd)? Ведь был бы удобный функционал типа Run(Download(www.site.ru/InstallPluIn.exe, "%TMP%\123.exe"))

Еще вопрос: В случае запуска скриптов отдельным процессом, я предусматриваю использование GlobalObject для того чтобы в режиме реального времени принимать логи другого процессе. Допустимо ли это? Не нарушит ли это стабильность работы приложения?
 
Коллеги, может быть мне стоит создать отдельную тему с полным описанием?

Насколько удаленный сервер безопасен? Известно, что нельзя доверять данным, пришедшим извне, тем более по широкодоступным средствам связи.

К чему необходимость в такой детализации части кода, вызвавшего ошибку? Так ли важно, что ошибка произошла в 24 символе 143 строки, если ошибка уже произошла и надо проверять логику алгоритма, исправлять код программы и снова тестировать?

В данном случае, как мне кажется, надо искать не обходные способы выхода из дочернего процесса, а разработать спецификацию для скриптов, которые будут выполняться под ScriptControl. В этой спецификации стоит особо оговорить способ завершения исполняемого скрипта (обычный выход, выход с возвратом кода завершения. аварийный выход с учетом завершения по прерыванию). И естественно в дочернем скрипте запретить команды вида WScript.Quit. И с исключениями надо быть очень осторожным - брошенные исключения ведут себя по-разному в зависимости от контекста исполнения - основная программа или подпрограмма. В большинстве случаев программные исключения не отлавливаемые либо не идентифицируемые.

quit:{
  function test_func(){
    WScript.Echo( 'test str 1');
    break quit;
    WScript.Echo( 'test str 2 (must not see this)');
  }
  WScript.Echo( 'str 1');
  test_func();
//  break quit;
  WScript.Echo( 'str 2 (must not see this)');
}

У меня на такую конструкцию ругается:
"1.js(4, 15) Ошибка компиляции Microsoft JScript: Метка не найдена"

Т.е. если WScript.Quit будет внутри функции - то скрипт просто не запустится.

this.FSO = fso = WScript.CreateObject("Scripting.FileSystemObject");

function LogError(e)
{
    WScript.Echo(e);
}

function isFile(Path)
{
    return fso.FileExists(Path);
}

function ReadTextFile(Path)
{
    if (!Path) return "";
    if (!isFile(Path)) return "";
    if (FSO.GetFile(Path).Size==0) return "";

    try 
    {
        var Stream = FSO.OpenTextFile(Path, 1, 0),
        Result = Stream.ReadAll();
        Stream.Close();
        return Result;
    }
    catch (e) {LogError(["ReadTextFile", Path].join("\t"))};
}


this.SC = WScript.CreateObject("ScriptControl");

var _WScript = {
    Name : WScript.Name,
    FullName : WScript.FullName, 
    Version : WScript.Version,
    BuildVersion : WScript.BuildVersion,
    ScriptName : WScript.ScriptName, 
    ScriptFullName : WScript.ScriptFullName, 
    StdIn : WScript.StdIn, 
    StdOut : WScript.StdOut, 
    StrErr : WScript.StdErr, 
    Arguments : {},
    Interactive : WScript.Interactive,
    
    Sleep : function (m) {return WScript.Sleep(m)},
    Quit : function () {},
    Echo : function (Msg) 
    {
        WScript.Echo(Msg)
    },
    CreateObject : function (ProgId, Pref) {return WScript.CreateObject(ProgId, Pref);},
    ConnectObject : function (Moniker) {return WScript.ConnectObject(Moniker);}, 
    DisconnectObject : function (a) {return WScript.DisconnectObject(a)}, 
    GetObject : function (Moniker) {return WScript.GetObject(Moniker);}
}

var SC = WScript.CreateObject("ScriptControl");

if (WScript.Arguments.Length==0) WScript.Quit(); var Code = ReadTextFile(WScript.Arguments.Item(0));
//var Code = "MsgBox(123);\n WScript.Quit();\nWScript.Echo(123); ";

SC.Language = "JScript";
SC.Reset();
SC.AddObject("WScript", _WScript);
SC.AddObject("MsgBox", _WScript.Echo);

if (SC.Language=="JScript") 
{
    Code = "quit:{"+Code.replace(/WScript\.Quit\([^)]*\)/gi, " break quit;")+"}";
    Code = Code.replace(/WScript.CreateObject\(([^,)]+),([^)]+)\)/gi, "new ActiveXObject($1)");
}

WScript.Echo(Code);

try
{
SC.AddCode(Code);
}
catch (e) 
{
    if (SC.Error)
    WScript.Echo([Code, SC.Error.Line, SC.Error.Column, SC.Error.Description].join("\r\n"));
}

Кстати, методы WScript.CreateObject, WScript.ConnectObject(Moniker), WScript.DisconnectObject(a), WScript.GetObject(Moniker) могут вести себя некорректно. Так, например, если подключиться к событиям объекта через WScript.CreateObject с указанием префикса, то события отлавливаться не будут.

Смысл задачи в том, как завершить работу ScriptControl.

Оставьте только один тест и Вы увидите, что исключение, брошенное в Quit не доходит до обработчика.

Если запускаемый скрипт на JS написан, тогда до внешнего скрипта исключение доходит. Из VBS - нет, это я видел. Имхо, главное - что внутренний скрипт прерывается в любом месте и выходит во внешний. Мне интересней - можно ли для VBS в создаваемый WScript.Quit вставить "On Error Goto 0" так, чтобы он на внутренний VBS действовал. У меня пока не получилось.