Why devMode is marked as @internal?

[feinstein]

Problem Statement

devMode is marked as @internal so we get a warning when we try to use it:

  @internal
  bool devMode = false;

Is there a reason for this to be @internal? I can see it being useful to be used as devMode = kDebugMode. This way we get exceptions when we are developing.

Solution Brainstorm

No response

Are you willing to submit a PR?

None

[buenaflor]

@denrase afaik this is one of the issues you worked on, maybe you have more context on this

[denrase]

We just use this internally in test expectations. When enabled, exceptions in user provided closures are re-thrown instead of being swallowed by the SDK. I'm not aware of any effort to make this a public API, so you should not rely on this flag being present in future releases. Maybe @kahest has some thoughts?

[kahest]

As @denrase mentioned, this is not intended or tested to be used outside of automated tests.

@feinstein what is the goal you are trying to achieve? Maybe there is a better way to solve this that is more in line with our SDK design principles.

[feinstein]

Correct me if I am wrong please, as I did a very quick look at the source code. I thought I could set devMode when kDebugMode, so no alerts are sent to Sentry when we are coding and thus generating a bunch of exceptions.

Also to control if exceptions/logs are shown in the console, for development, or are redirected to sentry only for production builds.

[buenaflor]

so no alerts are sent to Sentry when we are coding and thus generating a bunch of exceptions.

In that case I'd suggest using beforeSend if you haven't yet. You can configure it to filter out events based on your environment (dev, staging, prod, etc... for example).

[denrase]

@feinstein You have several options to achieve what you want:

You can enable the options.debug flag to log issues that might occur.

As for not sending events when developing locally, you can always just opt to not init the SDK, or, like @buenaflor mentioned, filter out all events in beforeSend

Another option might be to setup different environments with the [options.environment] flag. You can then filter your issues in the web UI.

The documentation of those flags has more infos that might be of interest to you.

[denrase]

@kahest Maybe calling this internal testing flag devMode is an issue in itself.

[stefanosiano]

@denrase let's rename it to automatedTestMode and add a comment to explicitly say that it's only used for tests