Today i stumbled across something in the RTL I'd like to discuss. When writing routines and implement error handling, i prefer to not raise execptions if i have a resultvalue(like Bool), even if the parametervalidation runs into an unwanted value. I simply return False and exit.

Today i stumbled across something in the RTL I'd like to discuss. When writing routines and implement error handling, i prefer to not raise execptions if i have a resultvalue(like Bool), even if the parametervalidation runs into an unwanted value. I simply return False and exit.
In procedures i do raise exceptions(no discussion about whether I should use a function with resultvalue here, just an example).

As i used ForceDirectories i encountered an exception ("Unable to Create Directory"). A path was given(by userinput), and just the result(worked, did not work) was expected.

However, looking into the function revealed, that it checked for it's parameter not being empty and otherwhise raising an exception(instead of just returning false):

if APath = '' then
begin
  //raise exception
end;

So i thought at least just preventing empty Path variables to be passed fixes this problem.

A path like this however:
FooFolder\

raises the same exception. When stepping through it, during itself calling recursively, it produces an empty Parameter by itself!
At this point I'd just have returned false, but here they do it the hard way.

I see no reason to raise an exception for something like this, the most interesting errors (access denied etc) are hidden internally anyway, so there is no other extended information you'd receive at this point. You end up with one single cornercase that kills it.

What do you think?