I understand the "Don't reinvent the wheel" sentinement, but at this point I'm not sure it's a good one to follow. In my 20+ years of development I've honestly not encountered any library that didn't have defects limiting it's use, causing it to crash, or causing some other random errors. I'm willing to bet that roughly 99.99% of all libraries out there are built with defensive programming in mind.
The trick is to use libraries but sandbox and abstract them to add another layer of safety. Avoid using the interfaces of the library directly, otherwise you'll get stung by the defects it contains. Write unit tests for every feature of the library that you need, and use nothing more. This has the added advantage of limiting vendor lockin.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I understand the "Don't reinvent the wheel" sentinement, but at this point I'm not sure it's a good one to follow. In my 20+ years of development I've honestly not encountered any library that didn't have defects limiting it's use, causing it to crash, or causing some other random errors. I'm willing to bet that roughly 99.99% of all libraries out there are built with defensive programming in mind.
The trick is to use libraries but sandbox and abstract them to add another layer of safety. Avoid using the interfaces of the library directly, otherwise you'll get stung by the defects it contains. Write unit tests for every feature of the library that you need, and use nothing more. This has the added advantage of limiting vendor lockin.