Non-Error exception captured with keys: error, headers, message, name, ok

[EternalPirate]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account (https://sentry.io/share/issue/0f0aeecaa08746389b64945abd4544fd/)

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:
• @angular/core

Version:

5.7.1 (@sentry/browser)
8.2.11 (@angular/core)

Description

I have initial setup for Angular app with global ErrorInterceptor
here how I send it

    const eventId = Sentry.captureException(error.originalError || error);
    Sentry.showReportDialog({ eventId });

and I get this (Non-Error exception captured with keys: error, headers, message, name, ok) error again and again, and can't understand what is wrong from the description and how to reproduce it.

[kamilogorek]

This means that the object you provide is not an instance of Error which holds the stacktrace in Angular app.

You should (as the message points to) use Sentry.captureException(error.error) or Sentry.captureException(error.message) depending on your needs.

[EternalPirate]

@kamilogorek oh ok) tnx

[EternalPirate]

@kamilogorek still getting this error, even with this

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

[Zeswen]

+1, still getting this error no matter how I put it.

sentry.error-handler.ts

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

package.json

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

[EternalPirate]

I decided to do this

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;
            }
        });

[Zeswen]

Thank you for the workaround @gchronos! I hope there will be a potential fix anytime soon.

[louieogrady]

Just chiming in to say I am also getting these errors. I'm using Angular 8 and after reading quite a few issues on this, I realise that it might be a case of me not handling the error properly in my error handling component. I've tried the workarounds suggested by others defining the exception before being passed to captureException but this hasn't reduced the errors. It'd be great if anyone could give some further input on this or I'll just have to use GChronos's (Thanks!) solution.

[franbueno]

+1

[stephane-dereppe]

+1

[kamilogorek]

Can someone provide repro that I could use to debug this? I tried to use base angular-cli app and I cannot reproduce this behavior. Thanks!

[xemil]

@kamilogorek I believe you can init a new Angular 8 project, and make a http request towards a endpoint returning 500 and not catch the error in the http service so it propagates to Sentry.

[jonathan-payiq]

I can chime in with some more info, this is our ErrorHandler:

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

In our Sentry tracking we always get duplicate events for these ones:

• Object.a Non-Error exception captured with keys: ...
• captureException Non-Error exception captured with keys: ...

(Other events are reported okay as one item in the list)

We have collected a couple hundreds of these "Non.Error"-events, and interestingly they all have the following in common:

• browser.name: Samsung Internet 100%
• browser: Samsung Internet 9.4 100%

And the errors are mostly the following:

{
  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
}

[hdayacr]

Ok I rendered the SentryErrorHandler injectable and implements ErrorHandler instead of extends and there are no more problems like that for me.
So I changed from

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;
 }
}

to

@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;
 }
}

I had the first config for 2 years without problems but since the upgrade to Angular 8 I have several sentry exceptions.

[schumannd]

@jonathan-payiq have you been able to find out what causes this? Or do you just ignore all those Non-Error exceptions now?

[jonathan-payiq]

We are currently ignoring them.
We figured out from the breadcrumbs that these happen when the webview/browser is in the background (not visible), so the fix for us is to prevent the fetch from happening while the page is not visible. Apparently Samsung browsers handle the network refresh badly when in background.

[mihaic195]

@jonathan-payiq how exactly are you ignoring them? Thanks in advance.

[szechyjs]

We are currently using the following to ignore it.

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

[rhcarvalho]

@kamilogorek were you able to reproduce the issue?

[kamilogorek]

Closing the issue, as it seems like the original issue has been partially resolved or there is a working solution. I'd prefer someone to create a new issue with a fresh description if it's still an issue.
Please do not hesitate to ping me if it is still relevant, and I will happily reopen and work on it.
Cheers!

[Rush]

It has not been resolved. I just tried to integrate Sentry with Angular 8 and found this issue.

[Rush]

I don't get it how can Sentry claim out of the box setup, it's completely false.

[kamilogorek]

Great catch @jakkn, thanks! Updated handler in the PR #2903

[sam0x17]

I'm having this issue on an Express app I just inherited. No idea how this could happen, but it seems to be happening for most errors the app throws, and I'm using the standard Express setup from the docs.

e.g. https://sentry.io/share/issue/bfd4f674c10b4b4a8b6a291dde8e2a66/

[tswaters]

I hit this same error, although it was for the express request handler and not angular. Basically I was calling next with a pojo instead of an Error object. I do some fun things in my own express error handler to turn it into something of interest, but because the sentryio request middleware goes first, it didn't get this marshalled error.

In the end, created a utility function that would turn whatever was provided into something more reasonable:

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))
  }
}

This muxes up the stack traces I think, but really if it was a pojo passed into this, there was no stack trace anyway.

In our instance, before this was fixed, the vast majority of events reported were for this particular issue and because it's a long-running node web server, breadcrumbs are near useless -- and all the errors get lumped into this one event type.

[doctorconceptual]

const exception = error.error || error.message || error.originalError || error;

this will evaluate to true/false

[PhilippMeissner]

const exception = error.error || error.message || error.originalError || error;

this will evaluate to true/false

Unlikely, while possible. It all comes down to what "error" you send down the stream. But after-all, this should include some kind of useful information.

[jacquesdev]

We are currently using the following to ignore it.

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

Why isn't this option documented anywhere?

[kamilogorek]

@jacquesdev https://docs.sentry.io/platforms/javascript/configuration/filtering/#decluttering-sentry

[rocklaam]

I decided to do this

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;
            }
        });

Thanks for your workaround, but I think we should add some null guards when getting value, otherwise it can cause the error: Type Exception: Cannot read properties of undefined (reading 'startsWith'), and send an unexpected error to Sentry.

[justinotero]

  ignoreErrors: [
    'Non-Error exception captured'
  ]

https://docs.sentry.io/clients/javascript/tips/

[bert2]

New docs and 5.16.0 just has been released - https://docs.sentry.io/platforms/javascript/angular/ I tried to make it as explicit and detailed as possible, and that's why it "may look" like a lot of code.

Hi @kamilogorek , what happend to the detailed documentation? Has it been removed since then? The only thing I could find is this: https://docs.sentry.io/platforms/javascript/guides/angular/troubleshooting/#events-with-non-error-exception

[kamilogorek]

I think this is where it lives now: https://docs.sentry.io/platforms/javascript/guides/angular/configuration/filtering/#decluttering-sentry

[bert2]

OK, thanks. Too bad it's missing lots of the helpful details you wrote though.

[awitherow]

ignoreErrors: ['Non-Error exception captured'] is now missing from this tips page above?

[DzmVasileusky]

One thing to note: if you will ignore non exception like errors you may miss something which needs to be fixed just because of the wrong error type.

In my case we are using it with Angular 14 like this

{ provide: ErrorHandler, useValue: Sentry.createErrorHandler({ showDialog: false }) },

and it seem to handle every error from every API
we have this error for objects like this

{
  error: {
    code: RequestFieldsTypesMismatched, 
    msg: "Something ....", 
    params: [Object]
  }, 
  headers: {
    lazyInit: [Function: <anonymous>], 
    lazyUpdate: None, 
    normalizedNames: [Object]
  }, 
  message: Http failure response for https://api.iterable.com/api/events/track: 400 OK, 
  name: HttpErrorResponse, 
  ok: False, 
  status: 400, 
  statusText: OK, 
  url: https://api.iterable.com/api/events/track
}

[LeLunZ]

@kamilogorek i am having troubles here.
When calling Sentry.captureException(error) in an angular 13 HTTP-Error-Interceptor, where error is a HTTPErrorResponse.

Sentry shows Error: Non-Error exception captured with keys: error, headers, message, name, ok

I don't understand if this is a issue on my side or if this is a wontfix from sentry.
In this thread are too many people saying they have this problem and others saying they dont.

[kamilogorek]

@LeLunZ are you using @sentry/browser or @sentry/angular? If latter, please mention it here #2744 so that team will see it pop up again (im not working on SDK part anymore)

[LeLunZ]

In @sentry/angular but the issue #2744 is about multiple errors not about having the Non-Error exception with HttpErrorResponse, should I still mention it there.

[kamilogorek]

Ah, you're using captureException directly. Then I believe you need to replicate the behavior that you can find here

sentry-javascript/packages/angular/src/errorhandler.ts

Lines 34 to 52 in a88a8bf

	function extractHttpModuleError(error: HttpErrorResponse): string | Error {
	// The `error` property of http exception can be either an `Error` object, which we can use directly...
	if (isErrorOrErrorLikeObject(error.error)) {
	return error.error;
	}
	// ... or an`ErrorEvent`, which can provide us with the message but no stack...
	if (error.error instanceof ErrorEvent && error.error.message) {
	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;
	}

[LeLunZ]

@kamilogorek thx you are the best. Wrote my own error extractor. That solves the problem
Didnt know that there could be so much different stuff in an HttpErrorResponse...

[haexyh]

We still get these errors with Angular 16 and @sentry/integrations 7.64.0, Can someone provide any update? Besides the workarounds, I would appreciate a fix from the package itself.

[mydea]

We still get these errors with Angular 16 and @sentry/integrations 7.64.0, Can someone provide any update? Besides the workarounds, I would appreciate a fix from the package itself.

Can you update to the latest version (there may have been improvements/fixes around this in the meanwhile - latest is 7.73.0 as of now)?

If that does not fix this, can you provide more detail on what you are capturing - if you are using Sentry SaaS, links to events would be helpful too.

[haexyh]

@mydea we filter these errors out with a regex. This workaround works out for us