Suggest: remove default throw behavior

[joshgoebel]

Suggestion: We silently swallow errors vs throwing, thereby preserving the page layout and properly rendering at least unhighlighted code blocks (class 'hljs', etc) rather than potentially doing NOTHING leaving the page in an even uglier state.

This should already be an edge case, the question is would it be nicer to go ahead and do our best to recover vs just giving up? I think in many types of failure conditions (such as a single broken/incompatible language) this would be preferable to the WHOLE library failing to work.

--- a/src/highlight.js
+++ b/src/highlight.js
@@ -749,7 +749,12 @@ https://highlightjs.org/
           value: escape(value)
         };
       } else {
-        throw e;
+        console.error(...);
+        return {
+          relevance: 0,
+          value: escape(value),
+          errorRaised: e.message
+        }
       }
     }
   }

[joshgoebel]

Related (examples where making this a softer error could have helped):

• fix: freeze built-in modes to prevent grammars altering them #2271
• (fix) contains self pointing to a top-level rule breaks #2263

[egor-rogov]

I think in many types of failure conditions (such as a single broken/incompatible language) this would be preferable to the WHOLE library failing to work.

It would be preferable for users, but when you are developing a new grammar you'd like to get errors. Maybe we need both behaviours (some API parameter for a strict mode, turned off by default, but on in developer.html)?

[joshgoebel]

Sure. I’m fine with a flag to enable the prior behavior for debugging/development. Some type of auto detect would be even cooler but I’m not sure what we could reliably key that off of. Perhaps localhost or file:// could auto trigger debug mode or is that over thinking it? In addition to manually enabling.

[egor-rogov]

Perhaps localhost or file:// could auto trigger debug mode

Sounds reasonable.