Error Handling

During a component's initialization it is often the case that the provided properties must contain a certain value or are of a certain type (though this is not the only time/location such checks are done throughout the codebase). In cases where these checks fail but still allow the component to function (such as not passing a valid theme to sl-alert) a warning is written to the console. In cases where these failed checks will cause the component to not function at all (such as passing an invalid timezone to the sl-date-time component) an error is thrown.

To provide the best user experience to a developer we wanted to make sure that the errors thrown in the latter scenario above were done in a manner allowing them to specifically identify when an error that was caught in their application came from this addon versus elsewhere in their application. The README explains how they can leverage this capability.

The initial intention was to be able to throw a specifc type of error within our error conditions rather than calling a function to do so, but due to current limitations in the exporting of modules and instantiation of classes we had to settle for the latter.

Another compromise we had to accept was having to track whether setErrorTypeThrown() was called directly from within the testing environment or internally by the codebase. setErrorTypeThrown() only needs to be exported in the testing environment to be used for validation of the functionality in tests but you are not able to conditionally export modules. Reference the first bullet point in the "Static vs. dynamic, or: rules and how to break them" section for more details.