Hi Niklas, On Sat, Aug 1, 2015 at 8:27 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> They should totally be handled. You need to catch the error and throw a >> defined exception, otherwise your public API will break if you choose to >> use another internal implementation. >> Additionally, you seem to assume that the library doesn't have to do >> things like cleanups in such a case. >> > > My thought is based on Design by Contract (Contract programming). > When parameter or environment does not satisfy contract, contract error > should be > resulted in program/process termination. > > Fixing inappropriate parameter or environment is not library/framework > author's > responsibility, but the developer's. i.e. > Caller(function/programmer/system admin) > has the responsibility that satisfies parameter/environment requirement. > If > requirement is not met, it's perfectly OK for library/framework to raise > fatal > errors/exceptions. e.g. "You need PHP 5.6 or greater" error. > I'll be more specific for "CSPRNG not available" error. If a author would like to handle the error and fallback to non crypt safe RNG, he/she should detect environment and execute alternative code for the environment. Catching exception and fallback to non crypt safe RNG is not optimal way for handling unsatisfactory environment. IMHO. If we need function that checks environment, we are better to provide one rather than let users to use exception. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
