[fdo-dev] Where to put improvements?

[Mateusz Loskot]

Robert Bray wrote:
> Mateusz,
> 
> Let's start discussing them here on the list. I'd like to get the RFC
> process started for FDO early in the new year, so that will be the
> mechanism for formalizing them and getting them approved by the PSC.

OK, RFC will be good, as we've already discussed.

But the improvements I have currently in mind, are pretty small and
related to places caught fast in the code as potentially dangerous,
while I'm working on the PostGIS provider.

Second sort of improvements is related to improving source code
readability and maintainability, so I think these
should be specified in a separate RFC, as a kind of policies.

OK, back to the initial issue I have had in mind.
Currently, functions like
FdoRdbmsSQLCommand::SetSQLStatement()
FdoStringP::SetString()
and other similar functions, copy-constructors and assignment
operators are not exceptions immune.

In case of exceptions, these functions leave state of the original
object affected.

Here is very simple example of how the SetSQLStatement can be
improved to be fully exceptions immune function,
so an instance of FdoRdbmsSQLCommand is much safer too:


// Sets the SQL statement to be executed as a string.
void FdoRdbmsSQLCommand::SetSQLStatement(const wchar_t* value)
{
    if (NULL != value)
    {
        // may throw
        wchar_t* tmp = wcscpy(new wchar_t[wcslen(value)+1], value);

        // should not throw
        delete[] m_SqlString;

        // assign new string safely
        m_SqlString = tmp;
    }
}


Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net