My idea, extremely summarized, would be to take the functions that
return false/null when they 'error', and instead make them actually
throw an error.
First of all, they definitely should not throw Error, because Errors are
for very specific types of things that mean the engine does not know
what to do - e.g. if you asked for an integer and you gave parameter
that can not be converted to integer, or you tried to use a function
which does not exist, and so on. Normal functionality should almost
always use Exception unless you have a really great reason not to.
Second, I don't see any point in such a huge BC break for people that
are fine with current return values. Exceptions is not something you can
ignore (even if you can easily ignore method returning false - sometimes
you don't want to, but sometimes you do), it's something that breaks
your application. In some APIs for some corner cases it might be OK, but
in general it's probably not something we'd ever want to do on a global
Third, I think throwing exceptions for routine situations that are
expected to happen (like file not being there, or data not being valid)
is wrong and this is what makes Java exceptions, for example, annoying.
They confuse "everything broken and world is on fire, head for the
exits" with "there's some dirt on the floor, bring the mop and clean it
up". I.e. situations which are expected to be handled and situations
where things are just gone wrong and it's best for this code do give up
Exceptions should be used for situations which are, well, exceptional -
ones that the code surrounding the call is unlikely to be able to fix -
e.g. trying to open file while giving the argument that can not be used
as a filename. Of course, the question what is "normal" for a given API
is very specific to the API - e.g. for a search API not finding any
result would be normal, but for an authorization API not finding certain
record in the database may be exceptional - but I think there should be
a distinction between the two. Which should be used in each specific
case depends a lot on API design and specifics of the case, but there
should be an option for both behaviors.