Add flexibility to report problems in different ways - #22
Conversation
|
Looks fine to me. What do you think @Nyholm? |
|
Thank you for this PR. I really like the idea but Im not sure about the implementation. Why do we need a I suggest we rewrite the protected static function reportInvalidArgument($message)
{
throw new InvalidArgumentException($message);
}That would also solve your problem, right? BTW this is a blocker for tagging 1.2. We really have to do this before or else this would be a BC break. |
|
Your proposal was my initial solution, but I realized it would break existing interface, so it would be a BC breaker. |
|
Awesome |
|
updated |
|
Great. Im 👍 What does @JustBlackBird think? You introduced the custom error reporting. |
|
Looks good. At the same time personally I don't think that many people will use |
|
So, everyone is happy about this PR. What can I do to make it happen ? |
|
Yes. We are all good. I know that @webmozart will merge this one and #24 as soon as he gets a minute over for open source work. |
|
Thanks all! |
Hi !
Further extending of #19 to allow report a problem in different ways via extending the class, while default behaviour is not changed.
Use case - I have a library used with a lot of messy, invalid input from it's users that needs to be fixed by the users of library.
When I do the assertions that raising the exceptions - it will crash their app. So far even if their input is not perfect, it works somehow (not in the best way, but at least some functionality is working due to autoconverting).
The goal is to be strict and raise an exception when user of lib will pass invalid input. But as a middle step I want to make extra release which will just warn him (like triggering a warning instead of breaking the flow with exception).
Currently one can't override the library to do anything else than raising an exception. With this change it would become possible.
What do you think @webmozart ?