Jint: agregue la capacidad de obtener un seguimiento de la pila de errores y excepciones

Creado en 12 nov. 2014  ·  3Comentarios  ·  Fuente: sebastienros/jint

Estoy construyendo un motor que usa Jint para ejecutar un archivo javascript con un montón de funciones.

El problema es que si hay

  • un error de sintaxis
  • un error de tiempo de ejecución
  • un lanzamiento nuevo Error ()

todo lo que obtiene de Jint es una JavaScriptException sin contexto sobre dónde ocurrió el error.

En este momento estoy relegado a agregar declaraciones de registro solo para encontrar el problema en el script.

Sería extremadamente útil si cualquier lanzamiento de Error () viniera con la propiedad stack completada con el stacktrace de las funciones js.

Comentario más útil

Tuve el mismo problema, donde algunos scripts largos serían extremadamente difíciles de depurar. Lo que hicimos fue envolver Engine.Execute en nuestro propio bloque try y volver a lanzar con los valores Engine.GetLastSyntaxNode().Location.Start . Ejemplo:

c# var engine = new Engine(); try { engine.Execute("some code that throws..."); } catch(JavaScriptException exc) { var location = engine.GetLastSyntaxNode().Location.Start; throw new ApplicationException( String.Format("{0} (Line {1}, Column {2})", exc.Error, location.Line, location.Column ), exc); }

Tenga en cuenta que sería mucho mejor si el objeto location fuera _siempre_ parte del objeto JavaScriptException .

Todos 3 comentarios

Tuve el mismo problema, donde algunos scripts largos serían extremadamente difíciles de depurar. Lo que hicimos fue envolver Engine.Execute en nuestro propio bloque try y volver a lanzar con los valores Engine.GetLastSyntaxNode().Location.Start . Ejemplo:

c# var engine = new Engine(); try { engine.Execute("some code that throws..."); } catch(JavaScriptException exc) { var location = engine.GetLastSyntaxNode().Location.Start; throw new ApplicationException( String.Format("{0} (Line {1}, Column {2})", exc.Error, location.Line, location.Column ), exc); }

Tenga en cuenta que sería mucho mejor si el objeto location fuera _siempre_ parte del objeto JavaScriptException .

Gracias, eso es muy útil.

Sigo pensando que sería muy valioso tener un stacktrace disponible. La razón es que (en mi caso) el script se ensambla dinámicamente, por lo que pasar de un número de línea a la línea real en el script dinámico requiere un poco de trabajo adicional.

Para algunos errores de análisis, encontré también la excepción Esprima.ParserException .
Y encontré útil agregar también el texto de la línea que causa el error (como se imprime en la excepción de ClearScript)

public void Run(string script)
{
    JintEngine.Execute(script);

    catch (Esprima.ParserException ex)
    {
        throw new ApplicationException($"{ex.Error} (Line {ex.LineNumber}, Column {ex.Column}), -> {ReadLine(script, ex.LineNumber)})", ex);
    }
    catch (Jint.Runtime.JavaScriptException ex) 
    {
        throw new ApplicationException($"{ex.Error} (Line {ex.LineNumber}, Column {ex.Column}), -> {ReadLine(script, ex.LineNumber)})", ex);
    }
}

private static string ReadLine(string text, int lineNumber)
{
    using var reader = new System.IO.StringReader(text);

    string line;
    int currentLineNumber = 0;

    do
    {
        currentLineNumber += 1;
        line = reader.ReadLine();
    }
    while (line != null && currentLineNumber < lineNumber);

    return (currentLineNumber == lineNumber) ? line : string.Empty;
}
¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

sebastienros picture sebastienros  ·  34Comentarios

christianrondeau picture christianrondeau  ·  10Comentarios

appel1 picture appel1  ·  25Comentarios

christianscheuer picture christianscheuer  ·  5Comentarios

asdfgasdfsafgsdfa picture asdfgasdfsafgsdfa  ·  17Comentarios