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

[Daniël Mantione]

Op Tue, 16 Oct 2007, schreef L:

> > Let's first discuss a plan, then we'll see about the name. Suppose we put =
> >
> > everything that does something with paths and files in a unit:
> >
> > * Extractfilepath and friends
> > * Exec, findfirst, etc.
> >
> > ... then it could be called something like fsutils, "fs" from filesystem.
> >
> > So, let's first discuss the purpose of the unit and which functions =
> >
> > types will be in it.
> >
> > Dani=EBl
> >
> 
> One thing that has come to my mind now is the exceptional raise calls in some of
> the functions.  Some of the functions don't contain raise calls, which is great
> because they are automatically standalone capable as is. Functions without any
> raise calls AFAIR are ExtractFilePath and friends. Sysutils
> 
> 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.
 
> What does a raise call rely on? I can play and find out, but maybe you know off
> hand.

Afaik it is a statement, therefore handled by the compiler.

> The raise call can be ifdefed.. which gets messy, which is why I probably forked
> the unit.. because sometimes a forked duplicate function is easier to maintain
> than a single ifdefed function. Now it is all coming back to me. However, it
> isn't all bad news.. as I said many functions do not rely on raise and can be
> moved to fsutils immediately without any hassle.

Exactly, we should not put ifdefs into sysutils. This would useless 
anyway, since then the decision is made at compile time, and users 
generally don't compile sysutils themselves. I agree a forked unit can be 
easier to maintain on itself, but on the other hand it causes a serious 
problem for the maintenance of the project, since updates and bugfixes 
will have to be applied in two places. Therefore moving the implementation 
of some group of related functions, which you have an interrest in using, 
without being forced to have the exceptions as well, is the only sane way 
of handling this.

> If a raise call can work in fsutils.pp somehow, that's the other option. I am
> not familiar with how raise calls work when you don't have a sysutils in the
> uses.. wasn't it one of the features added to fpc recently: the ability to use
> exceptions without sysutils some way? But would this require syntax changes
> anyhow, as a different style of raise is used when you don't have sysutils in
> uses?

There is no need for a raise call to work inside a fsutils. All that is 
needed is that sysutils raises an exception on an error condition, and 
this raise call can be in sysutils itself.

Compare again "inttostr". The actual implementation, "val", is in the 
system unit. The only thing sysutils does is that calls "val" and raises 
an exception on error.
 
Daniël