Emit error events rather than throwing

[jtbandes]

Changelog

Added an "error" event to the LabelPool and FontManager.

Docs

None

Description

Rather than throwing errors, emit them via an "error" event.

For FG-9839

[snosenzo]

Would it be possible/worth it to have a simple test for this?

[snosenzo]

What's the preference for dispatch error vs throw error? I feel like throw error gives more traceabability as to which call threw the error albeit certainly at the cost of needing to wrap functions that may error in a try catch. Dispatching makes the errors themselves a bit more of an implicit requirement to handle rather than more explicit or in your face. I think I prefer throwing errors, but I'm not totally against this

[jtbandes]

at the cost of needing to wrap functions that may error in a try catch

This was my issue with it -- especially when such functions are "non-obvious" that they may throw errors, like label.setText("foo"). It felt like that was such a basic function that it kinda made sense to not throw. The related change which I guess I didn't call out in the description is that this makes the error non-fatal, i.e. you will see some � boxes but it will render as many characters as it can rather than totally bailing out.

I could also see maybe some implementation that allows swapping between multiple atlas textures once we hit the size limit. Didn't feel like it was worth the complexity though. In practice it's very rare for labels to have so many unique characters and only happened in this case because a user was passing in corrupt string data.

[snosenzo]

you will see some � boxes but it will render as many characters as it can rather than totally bailing out.

I guess as long as it's evident that an error is occurring in some way then it's fine. Another option to make it less implicit would be to require passing an onError method to the constructor to handle these errors?
Either way I think it's fine though