Sentry-javascript: गैर-त्रुटि अपवाद कुंजियों के साथ कैप्चर किया गया: त्रुटि, शीर्षलेख, संदेश, नाम, ठीक

इसका मतलब है कि आपके द्वारा प्रदान की जाने वाली वस्तु Error का उदाहरण नहीं है जो कोणीय ऐप में स्टैकट्रेस रखती है।

आपको (जैसा कि संदेश इंगित करता है) अपनी आवश्यकताओं के आधार पर Sentry.captureException(error.error) या Sentry.captureException(error.message) करना चाहिए।

@kamilogorek ओह ठीक है) tnx

@kamilogorek अभी भी यह त्रुटि प्राप्त कर रहा है, यहां तक ​​​​कि इसके साथ भी

    const exception = error.error || error.message || error.originalError || error;
    const eventId = Sentry.captureException(exception);

+1, अभी भी यह त्रुटि हो रही है

संतरी.त्रुटि-हैंडलर.ts

export class SentryErrorHandler extends GeneralErrorHandler {
  ...
  handleError(error) {
    ...
    const exception = error.originalError || error.error || error
    Sentry.captureException(exception)
  }
}

पैकेज.जेसन

{
  ...
  "@angular/core": "^8.2.11",
  "@sentry/browser": "^5.7.1",
  ...
}

मैंने ऐसा करने का फैसला किया

Sentry.init({
            dsn: environment.sentryUrl,
            beforeSend(event, hint) {
                /* tslint:disable:no-string-literal only-arrow-functions */
                const isNonErrorException =
                    event.exception.values[0].value.startsWith('Non-Error exception captured') ||
                    hint.originalException['message'].startsWith('Non-Error exception captured');
                /* tslint:enable:no-string-literal only-arrow-functions */

                if (isNonErrorException) {
                    // We want to ignore those kind of errors
                    return null;
                }
                return event;
            }
        });

वर्कअराउंड @gchronos के लिए धन्यवाद! मुझे उम्मीद है कि जल्द ही किसी भी समय संभावित सुधार होगा।

बस यह कहने के लिए कि मुझे भी ये त्रुटियां मिल रही हैं। मैं कोणीय 8 का उपयोग कर रहा हूं और इस पर कुछ मुद्दों को पढ़ने के बाद, मुझे एहसास हुआ कि यह मेरे त्रुटि प्रबंधन घटक में त्रुटि को ठीक से संभालने का मामला नहीं हो सकता है। मैंने कैप्चर अपवाद को पारित करने से पहले अपवाद को परिभाषित करने वाले अन्य लोगों द्वारा सुझाए गए कामकाज की कोशिश की है लेकिन इससे त्रुटियों में कमी नहीं आई है। यह बहुत अच्छा होगा अगर कोई इस पर कुछ और इनपुट दे सकता है या मुझे बस जीक्रोनोस (धन्यवाद!) समाधान का उपयोग करना होगा।

+1

+1

क्या कोई रेप्रो प्रदान कर सकता है जिसका उपयोग मैं इसे डीबग करने के लिए कर सकता हूं? मैंने बेस कोणीय-क्ली ऐप का उपयोग करने की कोशिश की और मैं इस व्यवहार को पुन: पेश नहीं कर सकता। धन्यवाद!

@kamilogorek मेरा मानना ​​​​है कि आप एक नई कोणीय 8 परियोजना में प्रवेश कर सकते हैं, और एक समापन बिंदु 500 की ओर एक http अनुरोध कर सकते हैं और http सेवा में त्रुटि को नहीं पकड़ सकते हैं, इसलिए यह संतरी को प्रचारित करता है।

मैं कुछ और जानकारी के साथ जुड़ सकता हूं, यह हमारा एररहैंडलर है:

@Injectable()
export class SentryErrorHandler implements ErrorHandler {
  constructor() { }
  handleError(error) {
    Sentry.captureException(error.originalError || error.error || error);
  }
}

हमारे संतरी ट्रैकिंग में हमें हमेशा इनके लिए डुप्लिकेट ईवेंट मिलते हैं:

• Object.a गैर-त्रुटि अपवाद कुंजियों के साथ कैप्चर किया गया: ...
• captureException गैर त्रुटि अपवाद कुंजी के साथ कब्जा कर लिया: ...

(अन्य घटनाओं को सूची में एक आइटम के रूप में ठीक बताया गया है)

हमने इनमें से सैकड़ों "गैर-त्रुटि" -घटनाओं को एकत्र किया है, और दिलचस्प बात यह है कि इन सभी में निम्नलिखित समान हैं:

• ब्राउज़र.नाम: सैमसंग इंटरनेट 100%
• ब्राउज़र: सैमसंग इंटरनेट 9.4 100%

और त्रुटियां ज्यादातर निम्नलिखित हैं:

{
  error: [Object], 
  headers: [Object], 
  message: Http failure during parsing for https://foo.bar/baz, 
  name: HttpErrorResponse, 
  ok: False, 
  status: 200, 
  statusText: OK, 
  url: https://foo.bar/baz
}

ठीक है, मैंने SentryErrorHandler को इंजेक्शन योग्य प्रदान किया और ErrorHandler को विस्तारित करने के बजाय लागू किया और मेरे लिए इस तरह की कोई और समस्या नहीं है।
तो मैं . से बदल गया

export class SentryErrorHandler extends ErrorHandler {

 constructor() {
     super();
 }

 handleError(err: any): void {
     if (environment.production === true || environment.preprod === true) {
         Sentry.captureMessage(err.originalError || err);
     }
     throw err;
 }
}

प्रति

@Injectable()
export class SentryErrorHandler implements ErrorHandler {

 constructor() { }

 handleError(err: any): void {
     if (environment.production === true || environment.preprod === true) {
         Sentry.captureException(err.originalError || err);
     }
     throw err;
 }
}

मेरे पास बिना किसी समस्या के 2 साल के लिए पहला कॉन्फिगर था लेकिन एंगुलर 8 में अपग्रेड होने के बाद से मेरे पास कई संतरी अपवाद हैं।

@ जोनाथन-पायिक क्या आप यह पता लगाने में सक्षम हैं कि इसका क्या कारण है? या आप अभी उन सभी गैर-त्रुटि अपवादों को अनदेखा करते हैं?

फिलहाल हम उनकी अनदेखी कर रहे हैं।
हमने ब्रेडक्रंब से पता लगाया कि ऐसा तब होता है जब वेबव्यू/ब्राउज़र पृष्ठभूमि में होता है (दिखाई नहीं देता), इसलिए हमारे लिए फिक्स यह है कि पेज दिखाई न देने पर फ़ेच होने से रोका जाए। स्पष्ट रूप से सैमसंग ब्राउज़र पृष्ठभूमि में होने पर नेटवर्क रीफ्रेश को बुरी तरह से संभालते हैं।

@ जोनाथन-पायिक आप उन्हें कैसे अनदेखा कर रहे हैं? अग्रिम में धन्यवाद।

वर्तमान में हम इसे अनदेखा करने के लिए निम्नलिखित का उपयोग कर रहे हैं।

Sentry.init({
  ignoreErrors: [
    'Non-Error exception captured'
  ]
});

@kamilogorek क्या आप इस मुद्दे को पुन: पेश करने में सक्षम थे?

समस्या को बंद करना, क्योंकि ऐसा लगता है कि मूल समस्या आंशिक रूप से हल हो गई है या कोई कार्यशील समाधान है। अगर यह अभी भी एक मुद्दा है तो मैं किसी को नए विवरण के साथ एक नया मुद्दा बनाना पसंद करूंगा।
कृपया मुझे पिंग करने में संकोच न करें यदि यह अभी भी प्रासंगिक है, और मैं खुशी से फिर से खोलूंगा और इस पर काम करूंगा।
चीयर्स!

इसका समाधान नहीं किया गया है। मैंने सिर्फ संतरी को एंगुलर 8 के साथ एकीकृत करने की कोशिश की और इस मुद्दे को पाया।

मुझे समझ में नहीं आता कि संतरी कैसे लीक से हटकर दावा कर सकता है, यह पूरी तरह से झूठ है।

मुझे समझ में नहीं आता कि संतरी कैसे लीक से हटकर दावा कर सकता है, यह पूरी तरह से झूठ है।

@Rush एक प्रतिलिपि प्रस्तुत करने योग्य मामला प्रदान करें, जहां आप समझाते हैं और दिखाते हैं कि क्या गलत है, और फिर हम आपके दावे को सत्यापित कर सकते हैं।

@kamilogorek सच कहा जाना चाहिए, कि 6 महीने से अधिक समय से कोणीय के साथ काम नहीं कर रहा है, इसकी पुष्टि करने के लिए यहां पर्याप्त रिपोर्ट है, इस प्रकार आईएमओ को और रेप्रो मामलों की कोई आवश्यकता नहीं है, आप इसे आसानी से आसानी से ढूंढ सकते हैं। मैं खुद को जानता हूं कि ऐसा नहीं है, क्योंकि हमारे पास कोणीय v8, और अब v9 (कोई स्रोतमैप नहीं) का उपयोग करके हमारी परियोजना में एक ही समस्या है।

बिल्कुल, और इसके अलावा मैं मेरे लिए काम करने के लिए संतरी के लिए भुगतान कर रहा हूँ। यह एक ओपन सोर्स प्रोजेक्ट नहीं है जहां मैं अपने हाथ गंदे होने की उम्मीद करता हूं।

मुझे संतरी पसंद है लेकिन मैं विकल्प तलाश सकता था...

मैंने एक उदाहरण के रूप में एक https://github.com/gothinkster/angular-realworld-example-app ऐप का इस्तेमाल किया, ताकि हर कोई भी समान प्रजनन कर सके।

बेयरबोन क्लोन ऐप, सेंट्री के एंगुलर डॉक्स का अनुसरण किया और सोर्समैप्स अपलोड किया। यहाँ परिणाम हैं।

उदाहरण 1: टूटा हुआ तर्क

एक त्रुटि हैंडलर में कोणीय आपको क्या देता है + हम किस घटना को कैप्चर करते हैं:

यह UI में कैसा दिखता है:

नोट: सब कुछ जगह पर है, आप आसानी से कोड की सही लाइन को इंगित कर सकते हैं जो टूटा हुआ था, त्रुटि संदेश और त्रुटि प्रकार सही है, क्योंकि कोणीय आपको काम करने के लिए एक संपूर्ण Error ऑब्जेक्ट देता है।

उदाहरण 2: टूटी हुई सेवा कॉल

एक त्रुटि हैंडलर में कोणीय आपको क्या देता है + हम किस घटना को कैप्चर करते हैं:

यह UI में कैसा दिखता है:

नोट: यह बताने का कोई तरीका नहीं है कि किस प्रकार की त्रुटि हुई है, क्योंकि कोणीय आपको यह जानकारी नहीं देता है। हालाँकि, आप यह बताने के लिए क्रमबद्ध डेटा पर एक नज़र डाल सकते हैं, कि "404 Not Found" त्रुटि थी, जो कि _सबसे अधिक संभावना_ अमान्य XHR कॉल से आई थी। फिर, आप यह देखने के लिए ब्रेडक्रंब प्रवाह की जांच कर सकते हैं कि _in fact_ दिए गए url पर एक XHR कॉल था (जिसमें इस मामले में एक टाइपो शामिल था), जो एक सटीक DOM तत्व पर एक क्लिक से पहले था, जिसने इसे ट्रिगर किया। इस जानकारी के साथ, समस्या को ठीक करने के लिए 99% मामलों में यह पर्याप्त होना चाहिए।

हम केवल उसी के साथ काम कर सकते हैं जो हमें ढांचे द्वारा दिया गया है। अन्यथा, हमें ढांचे को ही बंदर-पैच करना होगा।

हम केवल उसी के साथ काम कर सकते हैं जो हमें ढांचे द्वारा दिया गया है। अन्यथा, हमें ढांचे को ही बंदर-पैच करना होगा।

क्या यह "हमारी समस्या नहीं" कहने का आपका तरीका है? संतरी पर स्विच करने से पहले (कुछ प्रतिस्पर्धियों से) इन एक्सएचआर त्रुटियों को ठीक से पकड़ लिया गया था और उन्होंने कोणीय त्रुटि हैंडलर के साथ एक ही इंस्टॉल विधि का उपयोग किया था।

@kamilogorek एक विक्रेता के रूप में आप ढांचे के साथ टिकट भी खोल सकते हैं। मुझे यकीन है कि इस पर कुछ ध्यान दिया जाएगा।

संतरी पर स्विच करने से पहले (कुछ प्रतिस्पर्धियों से) इन एक्सएचआर त्रुटियों को ठीक से पकड़ लिया गया था और उन्होंने कोणीय त्रुटि हैंडलर के साथ एक ही इंस्टॉल विधि का उपयोग किया था।

@szechyjs तो यह बहुत अच्छा होगा यदि आप इसके बजाय समाधान साझा कर सकते हैं, क्योंकि यह ओपन-सोर्स एसडीके है और यदि हम जानते हैं कि हम क्या लक्ष्य कर रहे हैं तो हम सुधारों पर पुनरावृति कर सकते हैं।

... आप ढांचे के साथ टिकट भी खोल सकते हैं। मुझे यकीन है कि इस पर कुछ ध्यान दिया जाएगा।

मैंने अभी-अभी संतरी के समर्थन से एक टिकट खोला और इस मुद्दे का हवाला दिया।

यहां एक राहगीर। मेरे मामले के लिए, मैं मूल निवासी प्रतिक्रिया में संभाले गए अस्वीकृति की रिपोर्ट करना चाहता हूं और मैं ओपी के समान त्रुटि को देखकर समाप्त हुआ। चूंकि the object you provide is not an instance of Error , मैं नीचे का उपयोग कर रहा हूं।

export interface IError extends Error {
  code?: ErrorCode
  msg?: string
}

export const appError = (code: ErrorCode, msg: string = ''): IError => {
  const errmsg = `code: ${code}, msg: ${msg}`
  const err: IError = new Error(errmsg)
  err.code = code
  err.msg = msg
  err.name = 'appError'
  return err
}

फिर मैं फोन करता हूँ

export const logError = (err: Error) => {
  sentry.captureException(err)
}

और मैं देखता हूँ

उम्मीद है ये मदद करेगा!

मेरे मामले में संतरी के ब्रेडक्रंब अनुभाग ने मुझे कारण बताने में बहुत मदद की। यह ज्यादातर तब हुआ जब कुछ बाहरी एपीआई पर 404 थे।

डॉक्स अपडेट और आवश्यक जेएस एसडीके परिवर्तन आ रहे हैं:

https://github.com/getsentry/sentry-docs/pull/1695/
https://github.com/getsentry/sentry-javascript/pull/2601

इसे इसी हफ्ते रिलीज किया जाना चाहिए! :)

इसके लिए आसान सुधार (क्योंकि यह केवल HTTP इंटरसेप्टेड त्रुटियों के साथ होता है):

handleError(error: Error | HttpErrorResponse | any) {
      // ... 
      if (error.constructor.name === "HttpErrorResponse") {
                error.error.Message + " (" + error.message + ")";
                error = error.error;
      }
      // ...
      Sentry.captureMessage(err.originalError || err.error || error);

     throw err;
 }

नए दस्तावेज़ और 5.16.0 अभी जारी किए गए हैं - https://docs.sentry.io/platforms/javascript/angular/
मैंने इसे यथासंभव स्पष्ट और विस्तृत बनाने की कोशिश की, और इसीलिए यह बहुत सारे कोड की तरह "दिख सकता है"।

@kamilogorek मुझे यह समस्या Vue ऐप पर भी आ रही है। क्या वहां कोई फिक्स है?

मेरा भी यही विचार है। अपवाद को vuejs संतरी एकीकरण त्रुटि हैंडलर में फेंक दिया गया है।
https://sentry.io/share/issue/eaf13a2455e04150aaaab595d0d7bafe/

@sblawrie आपके पास वास्तव में क्या समस्या है? कृपया कुछ और विवरण सहायक होंगे।
@cincauhangus ऐसा लगता है कि आपके कोड में कहीं आप वादा उदाहरण के साथ एक त्रुटि फेंक रहे हैं (नोट abort, always, catch, done कुंजी)।

कुछ इस तरह:

const promise = new Promise((resolve, reject) => (...));
// somehow somewhere in the code
function foo () {
  // ...
  throw promise
}

तो Vue के errorHandler को एक संपूर्ण वादा वस्तु मिल रही है, जहां यह Error उदाहरण होने की उम्मीद करता है।

@kamilogorek स्पष्टीकरण के लिए धन्यवाद। मैंने कुछ बदलाव किए हैं और अगर यह अभी भी कोई समस्या है तो मैं इसकी निगरानी करूंगा।

कोणीय 8 का उपयोग करना और एक ही समस्या गैर-त्रुटि अपवाद था। उदाहरण 'extractError' कोड को निम्नानुसार संशोधित करें:

private static extractError(error: any) {
    // Try to unwrap zone.js error.
    // https://github.com/angular/angular/blob/master/packages/core/src/util/errors.ts
    if (error && error.ngOriginalError) {
      error = error.ngOriginalError;
    }
    // We can handle messages and Error objects directly.
    if (typeof error === 'string' || error instanceof Error) {
      return error;
    }
    // If it's http module error, extract as much information from it as we can.
    if (error instanceof HttpErrorResponse) {
      // The `error` property of http exception can be either an `Error` object, which we can use directly...
      if (error.error instanceof Error) {
        return error.error;
      }
      // ... or an`ErrorEvent`, which can provide us with the message but no stack...
      if (error.error instanceof ErrorEvent) {
        return error.error.message;
      }
      // ...or the request body itself, which we can use as a message instead.
      if (typeof error.error === 'string') {
        return `Server returned code ${error.status} with body "${error.error}"`;
      }
      // If we don't have any detailed information, fallback to the request message itself.
      return error.message;
    }

    // ***** CUSTOM *****
    // The above code doesn't always work since 'instanceof' relies on the object being created with the 'new' keyword
    if (error.error && error.error.message) {
      return error.error.message;
    }
    if (error.message) {
      return error.message;
    }
    // ***** END CUSTOM *****

    // Skip if there's no error, and let user decide what to do with it.
    return null;
  }

मेरी Sentry.init beforeSend ऊपर @untilinvite के beforeSend उदाहरण के आधार पर संशोधित। यह परिवर्तन https://github.com/getsentry/sentry-javascript/issues/2169 से एक दूसरे लॉग संदेश को संभालने के लिए है, जो गैर-त्रुटि के रूप में भी हल हो रहा है।

 Sentry.init({
        dsn: AppConfig.envSettings.sentryDSN,
        maxBreadcrumbs: 50,
        environment: this.getEnvName(),
        integrations: [new Sentry.Integrations.Breadcrumbs({ console: false })],
        beforeSend(event, hint) {
          // Note: issue with double entries during http exceptions: https://github.com/getsentry/sentry-javascript/issues/2169
          // Note: issue with a second entry not being set correctly (as a non-error): https://github.com/getsentry/sentry-javascript/issues/2292#issuecomment-554932519
          const isNonErrorException = event.exception.values[0].value.startsWith('Non-Error exception captured');
          if (isNonErrorException) {
            if (!event.extra.__serialized__) {
              return null;
            }
            let realErrMsg = event.extra.__serialized__.error ? event.extra.__serialized__.error.message : null;
            realErrMsg = realErrMsg || event.extra.__serialized__.message;
            // this is a useless error message that masks the actual error.  Lets try to set it properly
            event.exception.values[0].value = realErrMsg;
            event.message = realErrMsg;
          }
          return event;
        }
      });

हमने 5.16.0 रिलीज के साथ डॉक्स में जोड़े गए परिवर्तन किए हैं और हमें अभी भी Non-Error exception captured with keys: error, headers, message, name, ok त्रुटियां मिल रही हैं। मुझे उम्मीद है कि @ संतरी/कोणीय पैकेज इन मुद्दों को ठीक करेगा?

कोणीय: v9.1
संतरी: v5.20

@szechyjs क्या आपने http इंटरसेप्टर के बारे में दूसरा भाग भी पढ़ा? यह आमतौर पर त्रुटि का सही ढंग से पता न लगाने का मुख्य मुद्दा है - https://docs.sentry.io/platforms/javascript/angular/

@szechyjs क्या आपने http इंटरसेप्टर के बारे में दूसरा भाग भी पढ़ा? यह आमतौर पर त्रुटि का सही ढंग से पता न लगाने का मुख्य मुद्दा है - https://docs.sentry.io/platforms/javascript/angular/

हम इंटरसेप्टर का उपयोग नहीं कर रहे हैं।

नमस्ते, मैंने इस मुद्दे पर कुछ समय बिताया है और पाया है कि error.error.message प्रकार की त्रुटियों पर HttpErrorResponse आवश्यक रूप से कोई जानकारी नहीं है। अगर हम कंस्ट्रक्टर को देखें तो हम देखेंगे कि एंगुलर मैसेज प्रोप को रूट ऑब्जेक्ट पर सेट करता है न कि ErrorEvent ।

https://github.com/angular/angular/blob/cb3db0d31b91bea14c7f567fe7e7220b9592c11b/packages/common/http/src/response.ts#L345

इस लाइन को बदलकर https://github.com/getsentry/sentry-javascript/blob/8eb72865dcd62ff719441105c7eda28007a07e9d/packages/angular/src/errorhandler.ts#L112
प्रति

if (error.error instanceof ErrorEvent && error.error.message)

त्रुटि हैंडलर return error.message; और अपेक्षित त्रुटि फेंक दी।

शानदार कैच @jakkn , धन्यवाद! पीआर में अपडेट किया गया हैंडलर https://github.com/getsentry/sentry-javascript/pull/2903

मुझे यह समस्या एक एक्सप्रेस ऐप पर आ रही है जिसे मैंने अभी विरासत में लिया है। यह नहीं पता कि यह कैसे हो सकता है, लेकिन ऐसा लगता है कि ऐप फेंकने वाली अधिकांश त्रुटियों के लिए हो रहा है, और मैं दस्तावेज़ों से मानक एक्सप्रेस सेटअप का उपयोग कर रहा हूं।

उदाहरण के लिए https://sentry.io/share/issue/bfd4f674c10b4b4a8b6a291dde8e2a66/

मैंने यह वही त्रुटि मारा, हालांकि यह एक्सप्रेस अनुरोध हैंडलर के लिए था और कोणीय नहीं। मूल रूप से मैं एक त्रुटि वस्तु के बजाय एक पूजो के साथ next कॉल कर रहा था। मैं अपने स्वयं के एक्सप्रेस त्रुटि हैंडलर में इसे रुचि के कुछ में बदलने के लिए कुछ मजेदार चीजें करता हूं, लेकिन क्योंकि संतरीओ अनुरोध मिडलवेयर पहले जाता है, इसे यह मार्शल त्रुटि नहीं मिली।

अंत में, एक उपयोगिता फ़ंक्शन बनाया जो कि जो कुछ भी प्रदान किया गया था उसे और अधिक उचित में बदल देगा:

export const handleMaybeError = err => {
  if (err instanceof Error) return err
  const newErr = new Error(err.message || 'unexpected')
  for (const [key, value] of Object.entries(err)) {
    newErr[key] = value
  }
  return newErr
}

export const someController = (req, res, next) => {
  try {
    await handleResponse(req, res)
  } catch (err) {
    next(handleMaybeError(err))
  }
}

यह मुझे लगता है कि स्टैक के निशान को बढ़ाता है, लेकिन वास्तव में अगर यह एक पूजो में पारित किया गया था, तो वैसे भी कोई स्टैक ट्रेस नहीं था।

हमारे उदाहरण में, इसे ठीक करने से पहले, रिपोर्ट की गई अधिकांश घटनाएं इस विशेष मुद्दे के लिए थीं और क्योंकि यह एक लंबे समय से चलने वाला नोड वेब सर्वर है, ब्रेडक्रंब बेकार हैं - और सभी त्रुटियां इस एक ईवेंट प्रकार में शामिल हो जाती हैं।

कॉन्स अपवाद = त्रुटि। त्रुटि || error.message || त्रुटि। मूल त्रुटि || त्रुटि;

यह सही/गलत का मूल्यांकन करेगा

कॉन्स अपवाद = त्रुटि। त्रुटि || error.message || त्रुटि। मूल त्रुटि || त्रुटि;

यह सही/गलत का मूल्यांकन करेगा

संभावना नहीं है, जबकि संभव है। यह सब नीचे आता है कि आप किस "त्रुटि" को स्ट्रीम में भेजते हैं। लेकिन आखिरकार, इसमें किसी प्रकार की उपयोगी जानकारी शामिल होनी चाहिए।