feat: add Blaze.setExceptionLogLevel() to configure exception log level

[nicolv]

What

Adds a new Blaze.setExceptionLogLevel(level) method that lets apps configure which console method is used when Blaze reports template exceptions.

Why

Fixes #314 — currently all template exceptions are reported via console.log, which means they don't show up in error trackers that only capture console.error (like Sentry). There's also no way to make the app fail-fast on template errors since exceptions are always logged as info level.

How

The default remains console.log to avoid breaking existing apps (as discussed in the issue). Apps that want exceptions in the error console can now call:

Blaze.setExceptionLogLevel('error');

Allowed levels: 'log', 'warn', 'error'.

The change is fully backward compatible — existing behavior is unchanged unless you opt in.

Testing

Existing tests should continue to pass. The default behavior is unchanged.

[CLAassistant]

All committers have signed the CLA.

[jankapunkt]

Thank you @nicolv for your contribution! Please review #495 and #481 to make sure, this is not a duplicate. If this is a duplicate then I am very sorry for not linking them in the #314 issue.

Both PRs are targeting 3.1.0 which is not published yet but we are working on it. If you like to contribute to 3.1.0 then please look at the milestones at https://github.com/meteor/blaze/milestone/11

Let me know how to proceed here.

[nicolv]

Thanks for the pointers! I've reviewed both PRs:

• Fix #314: Use console.error for reporting template exceptions #495 is already merged — it simply swaps console.log for console.error. My PR goes further by providing a configurable API (Blaze.setExceptionLogLevel()) so apps can choose 'log', 'warn', or 'error' rather than having it hardcoded.
• feat(blaze): Add visual error indicator for development #481 is a different feature (visual error indicator in dev) — no overlap with mine.

My PR still adds value on top of #495 because it gives developers control over the log level instead of forcing console.error for everyone. I'm happy to rebase onto release-3.1.0 if that's the preferred target branch. Let me know how you'd like to proceed!

[jankapunkt]

I changed the base to 3.1.0 but as you pointed out @nicolv you would have to rebase. Another important requirement for merging would be - that the default behavior (using console.log) remains untouched when not explicitly changed, in order to keep this working with APM tools.

Once you have rebased I am eager to review and test this one.