Closed stuwest closed 5 years ago
What is the problem we're trying to solve here? It's probably just my jetlag-riddled brain, but I'm having trouble discerning what magic getter / setters on the locale affords us here.
I also don't really understand the rationale behind a custom exception class. Seems like returning a WP_Error
here & checking for it with is_wp_error
would work ok & be less code.
The main benefit of the magic getters and setters is that we can set the locale by a simple assignment while assuring that the appropriate JSONs are loaded.
Possibly returning a WP_Error
would also work, I'll do some further experimentation. See it as a step on the way to get decent error handling :)
going to close this one for now as it's been a few years.
@akirk added some commits in #76 to create a custom exception type and add a magic
__set()
and__get()
methods for overloading. To focus discussion, I moved these commits to their own branchadd/exception-class
and this PR. I added another commit to with some docblock (HTphpcs
with the fullWordPress
coding standard) and rebase cleanup.@akirk, couple questions:
is_wp_error()
instead of try/catch/throw exception? I'm hazy on why we'd use one or the other.$message_id
s? seems it could be more useful if the exceptions threw a specific message (e.g. "The WordPress localeary
doesn't have a corresponding CLDR locale loaded; see ___ to download it.") than a generic exception constants.set_locale()
. Do you see other ways we'd use them?@jblz, any thoughts?