[fdo-dev] Assertions

[Mateusz Loskot]

Greg Boone wrote:
> Mateusz Loskot wrote: Greg Boone wrote:
>> 
>> Since you are writing the PostGIS provider within the GenericRDBMS 
>> framework we expect to be able to build and test the PostGIS 
>> provider in the same manner and style as the MySQL and ODBC
>> providers. This means we expect you to write unit tests for the
>> PostGIS provider in a CppUnit style framework.
> 
> Greg,
> 
> Yes, I'm going provide well working CppUnit-based tests for PostGIS
> provider. And this subject is not influenced by my inclination use
> assertions.
> 
>> From our perspective, the build team are users as much as our
>> external clients such as MapGuide. The build team will building the
>> provider in Debug mode and executing the unit tests in Debug mode
>> on a daily basis.
> 
> And if the build team will get assertion catch, it does - again -
> mean that there is a serious bug and the development team has to deal
>  with it.
> 
> [GB] The primary issue here is that we run numerous builds and unit 
> tests every night which take many hours to complete.

Greg,

I think, I understand it well though I don't run hours-taking
builds myself.

> If an assert occurs and the build is halted it will have to be 
> restarted the next night. We try and avoid this possibility to the
> best of our abilities.

If assert occurs this mean there is a bug that should be fixed,
programmer's bug, not user's bug (invalid input, etc.).
So, I can't understand this assert avoiding policy.

> It is essential that we are able to build and test all our products
> and collect a clear documented record of the failures and exceptions
> that have occurred without requiring human interaction.


For me as a programmer, this policy is useless because
exceptions are useless here. Do your exceptions run abort() on failure
to generate core dump file so programmer has a chance to debug program
with all conditions just like during failure?
I assume your exceptions does not run abort() because it would
stop execution. Assert provides better context details than exception
(exceptions according common meaning).

Greg, excause me, but I feel uncomfortable because I'd not want
to say someone what he should do, how he should work, etc.
I know how I work and what I do to provide good quality (asserts are
included here). I feel responsible for a programmer that will
maintain my code in future. So, I'm responsible to provide my code with
pre-/post-conditions checked, and highly covered with tests against
programmer's and user's errors. Certainly, I can forget about my
personal policies and I'll do if that's my role.

So, I hope you don't mind I'll stop to pursue my
belief here :-)

>> It is critical that all tests be able to be executed without
>> asserting or throwing an unhandled exception and all errors
>> reported through standard CppUnit error handling/reporting
>> mechanisms.
>> 
>> The above 2 paragraphs deal with the newly developing PostGIS
> 'provider'
>> code base. As for any modifications you plan for existing
>> GenericRDBMS libraries such as RDBI, we expect that existing coding
>> standards (as seen in the existing subversion files) be followed.
>> If Asserts are not used in these components now then please do no
>> introduce that behavior in new code being submitted.
> 
> Greg, I have to confess that this rule abut not using assertions (I
> mean pre-/post-conditions and invariants assertions, but not Unit
> Test assertions) is ridiculous. It's like "please, don't run your
> code under debugger". This rule dictates to not to use one of the
> important tool in programmer's toolbox. IMHO without it, it will be
> hard and time consuming to provide good quality of code, with high 
> percentage of LOC executed that means tested.
> 
> Sorry, but I can't "walk on the line" without good assecuration. I'll
> use tools provided by C++ language for testing and debugging but I'll
> also stick to FDO rulse about Unit Test.
> 
> 
> [GB] Mateusz, I would ask that you respect our coding standards for 
> existing GenericRdbms libraries. As mentioned above, my only firm 
> statement about not using assertions was when discussing modifying 
> existing GenericRdbms code such as RDBI or GDBI.

Greg,
I'm sorry if I misunderstood you. Now, it's clear.
As I said above, I'll drop my policies and stick to yours.

> (Latitude will be provided in the PostGIS provider code base)
> Since the existing
> GenericRdbms code is packaged into existing shipping products such as
>  Autodesk Map and Autodesk MapGuide Enterprise, any submissions to
> these libraries is expected to meet these existing coding guidelines.
> Code that does not meet these guidelines will be rejected when
> submitted for code review.

Perfectly understood.

Now, what about review of my code?
Am I supposed to rewrite some parts? Does it qualify to submit to SVN?

Best regards
-- 
Mateusz Loskot
http://mateusz.loskot.net