Is there any kind of mechanism to listen for or observe errors at runtime like a callback? Is this all done through the console log? i’m trying to determine how i could determine which errors are “catastrophic”, which are coming from needle, and which are coming from Unity!
by user 423673039482257418
Do you have an example for what you’d like to catch? There’s a lot of callbacks 
A failure for the needle engine to initialize in the browser comes to mind. Is that too broad? I’m specifically curious if there’s a unified error stream of some kind that the engine provides, or if instead all errors are dumped to the console, including those directly from say, Unity?
by user 423673039482257418
Unity errors will never show up in the browser - you’ll see those in the Unity console as usual (Unity has nothing to do with your scene anymore once you’re in the browser)
What you can use for getting specific or all exceptions in the browser is:
window.addEventListener("error", (event) => { and
or window.addEventListener("unhandledrejection", (event) => { for example
Let us know if you have a more specific failure that you’d like to tackle 
Oh and of course you can wrap the console.error call. Just keep a reference to the original method and call it to not just “eat” the error
E.g.
const originalMethod = console.error;
console.error = function(...args:any[]) {
originalMethod.apply(console, args);
// <your additional error handling>
}
The last example is somewhat ugly because it changes the location the error is logged from in the browser console.
Okay that’s extremely useful thanks! It’d also be helpful to know if there is a particular formatting for errors that come from needle internals that suggest that a raised error is catastrophic in nature i.e experience ending - but that may be up to the client developer to determine?
by user 423673039482257418
Errors from the core should never be catastrophic in nature, otherwise we would certainly treat that as bug.
There’s some errors logged as “Not Supported:” for particular component creation scenarios, and otherwise we’re differentiating between errors and warnings and lean towards warnings for things that don’t affect operation (e.g. when you incorrectly call some methods we warn instead of error).