[fpc-devel] Re: fpc-devel Digest, Vol 40, Issue 16

[Daniël Mantione]

y

Op Tue, 16 Oct 2007, schreef L:

> > Functions like strtoint however have raise calls.
> 
> > > Yes, but there already exists a raise-less version of strtoint, called
> > > "val". So, there is IMO absolutely no need for an exceptionless version of
> > > strtoint in another unit.
> 
> Of course we can use our own functions that emulate what is in the sysutils
> unit.. but if they aren't drop in replacements this means that code is broken
> and now we have to add Val calls and Str calls instead of just using a drop in
> replacement.
> 
> The str() and val() functions I use occasionally, and I know turbopascal
> programmers had to use them.. but they are not drop in replacements. One of the
> goals of compactsysutils was to be a drop in replacement.  It is nice to be able
> to immediately convert a string to integer instead of using var params or OUT
> params. There is a way to build a StrToInt that still reports errors.. it
> returns a zero on error.

The whole reason why strtoint can work without var paramaters is that it 
throws as exception. You can only write e:=a(b(c(inttostr(d))) if you 
don't need to check an error condition.

If you have to check for the error condition, you can just as well use a 
var parameter. In short:

x:=strtoint(s);
if (s<>'0') and (x=0) then
  {handle error};
e:=a(b(c(x));

... is no improvement over:

val(s,x,code);
if code<>0 then
  {handle error};
e:=a(b(c(x));

Therefore, an exceptionless "strtoint" is not a drop in replacement, you 
need to recode your error handling. If you do so you can just as well 
replace it by val.

So, if you want to write e:=a(b(c(inttostr(d))); you have to pay the price 
for exception handling.

Daniël