Jak uzyskać numer linii funkcji wywołującej JavaScript? Jak uzyskać adres URL źródła wywołującego JavaScript?

Do uzyskania nazwy funkcji wywołującej JavaScript używam następującego:

var callerFunc = arguments.callee.caller.toString();
callerFuncName = (callerFunc.substring(callerFunc.indexOf("function") + 8, callerFunc.indexOf("(")) || "anoynmous")

Czy istnieje sposób na sprawdzenie numeru wiersza, z którego wywołano metodę?

Czy istnieje również sposób na pobranie nazwy pliku JavaScript, z którego wywołano metodę? Lub źródłowy adres URL?

To działa dla mnie w chrome / QtWebView

function getErrorObject(){
    try { throw Error('') } catch(err) { return err; }
}

var err = getErrorObject();
var caller_line = err.stack.split("\n")[4];
var index = caller_line.indexOf("at ");
var clean = caller_line.slice(index+2, caller_line.length);

Rozwiązanie kangaxa wprowadza niepotrzebny zakres try..catch. Jeśli potrzebujesz uzyskać dostęp do numeru linii czegoś w JavaScript (o ile używasz przeglądarki Firefox lub Opera), po prostu uzyskaj dostęp (new Error).lineNumber.

Byłem zaskoczony, że większość tych odpowiedzi zakładała, że ​​chcesz obsłużyć błąd, a nie tylko wyprowadzić pomocne ślady debugowania również dla normalnych przypadków.

Na przykład lubię używać takiego console.logopakowania:

consoleLog = function(msg) {//See https://stackoverflow.com/a/27074218/470749
    var e = new Error();
    if (!e.stack)
        try {
            // IE requires the Error to actually be thrown or else the 
            // Error's 'stack' property is undefined.
            throw e;
        } catch (e) {
            if (!e.stack) {
                //return 0; // IE < 10, likely
            }
        }
    var stack = e.stack.toString().split(/\r\n|\n/);
    if (msg === '') {
        msg = '""';
    }
    console.log(msg, '          [' + stack[1] + ']');        
}

To kończy się wypisywaniem na moją konsolę wyniku takiego jak następujący:

1462567104174 [getAllPosts@http://me.com/helper.js:362:9]

Zobacz https://stackoverflow.com/a/27074218/, a także Prawidłowe opakowanie dla console.log z poprawnym numerem linii?

Często osiąga się to przez wyrzucenie błędu z bieżącego kontekstu; następnie analizuje obiekt błędu pod kątem właściwości takich jak lineNumberi fileName(które mają niektóre przeglądarki)

function getErrorObject(){
  try { throw Error('') } catch(err) { return err; }
}

var err = getErrorObject();

err.fileName;
err.lineNumber; // or `err.line` in WebKit

Nie zapomnij o tym callee.caller właściwość jest przestarzała (i przede wszystkim nigdy nie była w 3. edycji ECMA).

Pamiętaj również, że dekompilacja funkcji jest określona jako zależna od implementacji, więc może dać całkiem nieoczekiwane wyniki. Pisałem o tym tutaj i tutaj .

Wygląda na to, że trochę się spóźniłem :), ale dyskusja jest dość interesująca, więc ... proszę bardzo ... Zakładając, że chcesz zbudować moduł obsługi błędów i używasz własnej klasy obsługi wyjątków, takiej jak:

function  errorHandler(error){
    this.errorMessage = error;
}
errorHandler.prototype. displayErrors = function(){
    throw new Error(this.errorMessage);
}

I opakowujesz swój kod w ten sposób:

try{
if(condition){
    //whatever...
}else{
    throw new errorHandler('Some Error Message');
}
}catch(e){
    e.displayErrors();
}

Najprawdopodobniej będziesz mieć moduł obsługi błędów w oddzielnym pliku .js.

Zauważysz, że w konsoli błędów przeglądarki Firefox lub Chrome pokazany numer linii kodu (i nazwa pliku) to linia (plik), która zgłasza wyjątek „Błąd”, a nie wyjątek „ErrorHandler”, który naprawdę chcesz, aby przeprowadzić debugowanie łatwo. Zgłaszanie własnych wyjątków jest świetne, ale w przypadku dużych projektów ich lokalizacja może być sporym problemem, zwłaszcza jeśli mają podobne komunikaty. Więc co możesz zrobić, to przekazać odniesienie do rzeczywistego pustego obiektu Error do swojego modułu obsługi błędów, a to odniesienie będzie zawierało wszystkie potrzebne informacje (na przykład w przeglądarce Firefox możesz uzyskać nazwę pliku, numer wiersza itp. ; w chrome otrzymasz coś podobnego, jeśli przeczytasz właściwość „stack” instancji Error). Krótko mówiąc, możesz zrobić coś takiego:

function  errorHandler(error, errorInstance){
    this.errorMessage = error;
    this. errorInstance = errorInstance;
}
errorHandler.prototype. displayErrors = function(){
    //add the empty error trace to your message
    this.errorMessage += '  stack trace: '+ this. errorInstance.stack;
    throw new Error(this.errorMessage);
}

try{
if(condition){
    //whatever...
}else{
    throw new errorHandler('Some Error Message', new Error());
}
}catch(e){
    e.displayErrors();
}

Teraz możesz uzyskać rzeczywisty plik i numer wiersza, który zgłosił niestandardowy wyjątek.

Numer linii jest w rzeczywistości czymś statycznym, więc jeśli chcesz go tylko do logowania, może być wstępnie przetworzony za pomocą czegoś takiego jak łyk. Napisałem małą wtyczkę, która robi dokładnie to:

var gulp = require('gulp');
var logLine = require('gulp-log-line');
gulp.task('log-line', function() {
    return gulp.src("file.js", {buffer : true})
    //Write here the loggers you use.
        .pipe(logLine(['console.log']))
        .pipe(gulp.dest('./build'))

})

gulp.task('default', ['log-line'])

Spowoduje to dołączenie nazwy pliku i wiersza do wszystkich dzienników z console.log, więc console.log(something)stanie się console.log('filePath:fileNumber', something). Zaletą jest to, że teraz możesz konkatować swoje pliki, transponować je ... i nadal otrzymasz linię

Zdaję sobie sprawę, że jest to stare pytanie, ale istnieje metoda o nazwie console.trace("Message"), która pokaże numer linii i łańcuch wywołań metod, które doprowadziły do ​​dziennika, wraz z przekazaną wiadomością. Więcej informacji na temat sztuczek związanych z logowaniem w JavaScript można znaleźć tutaj na stronie freecodecamp oraz w tym poście na blogu

Jeśli chcesz znać numer linii do celów debugowania lub tylko podczas programowania (z jakiegoś powodu), możesz użyć Firebug (rozszerzenie przeglądarki Firefox) i wyrzucić wyjątek.

Edycja :

Jeśli naprawdę z jakiegoś powodu musisz to zrobić w środowisku produkcyjnym, możesz wstępnie przetworzyć pliki javascript, aby każda funkcja mogła śledzić linię, w której się znajduje. Wiem, że niektóre frameworki, które znajdują pokrycie kodu, używają tego (na przykład JSCoverage ).

Załóżmy na przykład, że Twoje pierwotne połączenie to:

function x() {
  1 + 1;
  2 + 2;
  y();
}

Możesz napisać preprocesor, aby zrobić to w:

function x() {
  var me = arguments.callee;
  me.line = 1;
  1 + 1;
  me.line = 2;
  2 + 2;
  me.line = 3;
  y();
}

Następnie y()możesz arguments.callee.caller.linepoznać linię, z której została wywołana, na przykład:

function y() {
  alert(arguments.callee.caller.line);
}

Tak to zrobiłem, przetestowałem to zarówno w Firefoksie, jak i Chrome. Umożliwia to sprawdzenie nazwy pliku i numeru wiersza miejsca, z którego wywoływana jest funkcja.

logFileAndLineNumber(new Error());

function logFileAndLineNumber(newErr)
{
   if(navigator.userAgent.indexOf("Firefox") != -1)
   {
      var originPath = newErr.stack.split('\n')[0].split("/");
      var fileNameAndLineNumber = originPath[originPath.length - 1].split(">")[0];
      console.log(fileNameAndLineNumber);
   }else if(navigator.userAgent.indexOf("Chrome") != -1)
   {
      var originFile = newErr.stack.split('\n')[1].split('/');
      var fileName = originFile[originFile.length - 1].split(':')[0];
      var lineNumber = originFile[originFile.length - 1].split(':')[1];
      console.log(fileName+" line "+lineNumber);
    }
}

Oto co napisałem na podstawie informacji znalezionych na tym forum:

Jest to część MyDebugNamespace, Debug jest najwyraźniej zarezerwowana i nie będzie działać jako nazwa przestrzeni nazw.

    var DEBUG = true;

...

    if (true == DEBUG && !test)
    {
        var sAlert = "Assertion failed! ";
        if (null != message)
            sAlert += "\n" + message;
        if (null != err)
            sAlert += "\n" + "File: " + err.fileName + "\n" + "Line: " + err.lineNumber;
        alert(sAlert);
    }

...

Jak zadzwonić:

    MyDebugNamespace.Assert(new Error(""), (null != someVar), "Something is wrong!")

W mojej przestrzeni nazw zawarłem dwie funkcje ze zmienną liczbą argumentów wywołujących ten kod podstawowy, aby opcjonalnie pominąć komunikat lub błąd w wywołaniach.

Działa to dobrze w przeglądarkach Firefox, IE6 i Chrome zgłaszają nazwę pliku i numer wiersza jako niezdefiniowane.

poniższy kod działa u mnie w Mozilli i Chrome.

Jego funkcja dziennika, która pokazuje nazwę pliku i linię dzwoniącego.

log: function (arg) {
    var toPrint = [];
    for (var i = 0; i < arguments.length; ++i) {
        toPrint.push(arguments[i]);
    }

    function getErrorObject(){
        try { throw Error('') } catch(err) { return err; }
    }

    var err = getErrorObject(),
        caller;

    if ($.browser.mozilla) {
        caller = err.stack.split("\n")[2];
    } else {
        caller = err.stack.split("\n")[4];
    }

    var index = caller.indexOf('.js');

    var str = caller.substr(0, index + 3);
    index = str.lastIndexOf('/');
    str = str.substr(index + 1, str.length);

    var info = "\t\tFile: " + str;

    if ($.browser.mozilla) {
        str = caller;
    } else {
        index = caller.lastIndexOf(':');
        str = caller.substr(0, index);
    }
    index = str.lastIndexOf(':');
    str = str.substr(index + 1, str.length);
    info += " Line: " + str;
    toPrint.push(info);

    console.log.apply(console, toPrint);
}

Mój wkład w niestandardowe błędy w JavaScript:

1. Po pierwsze, zgadzam się z tym facetem @BT w Inheriting from the Error - gdzie jest właściwość wiadomości? , musimy to poprawnie zbudować (właściwie musisz użyć biblioteki obiektów js, moja ulubiona: https://github.com/jiem/my-class ):

   window.g3 = window.g3 || {};
   g3.Error = function (message, name, original) {
        this.original = original;
        this.name = name || 'Error.g3';
        this.message = message || 'A g3.Error was thrown!';
        (original)? this.stack = this.original.stack: this.stack = null;
        this.message += '<br>---STACK---<br>' + this.stack;
    };
   
    var ClassEmpty = function() {};
    ClassEmpty.prototype = Error.prototype;
    g3.Error.prototype = new ClassEmpty();
    g3.Error.prototype.constructor = g3.Error;

2. następnie powinniśmy zdefiniować globalną funkcję obsługi błędów (opcjonalnie) lub skończą one na silniku:

   window.onerror = printError; 
   function printError(msg, url, line){
       document.getElementById('test').innerHTML = msg+'<br>at: '+url+'<br>line: '+line;
       return true;
   }

3. na koniec powinniśmy uważnie zgłaszać nasze niestandardowe błędy:

   //hit it!
   //throw new g3.Error('Hey, this is an error message!', 'Error.Factory.g3');
   throw new g3.Error('Hey, this is an error message!', 'Error.Factory.g3', new Error());

Tylko przy przekazywaniu trzeciego parametru jako new Error() jesteśmy w stanie zobaczyć stos z numerami funkcji i linii!

Na 2 funkcja radzi sobie również z błędami zgłaszanymi przez silnik.

Oczywiście prawdziwe pytanie brzmi, czy naprawdę tego potrzebujemy i kiedy; zdarzają się przypadki (moim zdaniem 99%), w których wystarczy wdzięczny powrót falsei pozostawienie tylko niektórych punktów krytycznych do pokazania z wyrzuceniem błędu.

Przykład: http://jsfiddle.net/centurianii/m2sQ3/1/

console.log(new Error);

Pokaże ci cały utwór.

Aby określić, w którym wierszu jest coś, musisz przeszukać cały kod pod kątem kodu, który zajmuje dany wiersz, i policzyć znaki „\ n” od góry do tego, który Cię interesuje, i dodać 1.

W rzeczywistości robię to właśnie w aplikacji, którą piszę. Jest to walidator najlepszych praktyk dla HTML i wciąż jest intensywnie rozwijany, ale proces wyświetlania błędów, który Cię interesuje, został zakończony.

http://mailmarkup.org/htmlint/htmlint.html

Odpowiedzi są proste. Nie i nie (nie).

Do czasu uruchomienia javascript koncepcja plików źródłowych / adresów URL, z których pochodzą.

Nie ma również sposobu na określenie numeru linii, ponieważ ponownie, do czasu wykonania, pojęcie „linii” kodu nie ma już znaczenia w Javascript.

Konkretne implementacje mogą zapewniać punkty zaczepienia API, aby umożliwić uprzywilejowany dostęp kodu do takich szczegółów w celu debugowania, ale te interfejsy API nie są narażone na zwykły standardowy kod JavaScript.