Closed kelunik closed 7 years ago
I'm not sure whether that's really necessary; I mean it'll be easily visible in the stacktrace?
What would the use case for this be? When calling what ever method causes the exception you already know the ID anyway
Dunno, just throwing out ideas. Thought it might be usable in debugging with a debug driver that tracks where watchers have been created.
@WyriHaximus @bwoebi The code causing the exception will probably not catch such an exception, because it's always a programming error. But there might be logs that might tell you, which watcher that was. I know that at least room-11/jeeves
logs watcher IDs in some situations. A catch-all handler could then log the watcher ID in a context array, making it easier to use in structured searches. This is especially useful, if watcher IDs are suddenly a
and ab
and are
, because we no longer use spl_object_hash
, but $i = "a"; $i++
instead to create watcher IDs, so that they're unique per driver and process.
I wouldn't be opposed to actually overloading __toString() and taking the invalid id as ctor parameter.
@bwoebi Please never overload __toString()
, especially not for exceptions.
@bwoebi If we used an interface, we wouldn't have to care about __construct
, just the API to get the invalid ID.
@kelunik uh, I didn't mean overriding __toString, but using our own fixed message, so that it is everywhere the same. [A benefit an interface would not have.]
What's the advantage of a fixed message? A implementation should be able to provide additional information in it, maybe the creation date of the watcher ID in a debug driver.
An implementation always can overload our ctor. It just guarantees a fixed messages implementations can take as reference when customizing.
Should we add a method to
InvalidWatcherException
to expose the invalid passed ID in the exception? If we do that, it might be a good idea to turn it into an interface instead. Once we have an interface, I'd be nice to have PHP 7 and just extendThrowable
.