Subject: Re: #include ap_EditMethods.cpp
From: Paul Rohr (paul@abisource.com)
Date: Fri Jan 21 2000 - 19:09:49 CST
At 03:45 AM 1/20/00 -0600, sam th wrote:
>On further consideration, I think that removing IEStatus entirely would be
>a bad idea.
>1 Not to sound like a lazy programmer, but it is used in 41 files in
>probably 80 functions.
If making the change is the Right Thing to do (see below), then that's what
we should do. Sometimes when code gets sloppy, the fix needed may be ugly,
messy, and just plain no fun. But eventually someone needs to put on their
"code janitor" hat and spread some sawdust.
>2 Most importantly, IEStatus variables are used to maintain the
>internal state of some of the classes, and I don't like the idea of using
>error codes for this.
This sounds like a plausible argument, so I went ahead and took a look.
Here's what I found:
1. Clearly, all of the (relatively few) uses of IEStatus outside of the
impexp code are for reporting errors:
abi/src/text/ptbl/xp/pd_Document.cpp
abi/src/wp/ap/beos/ap_BeOSApp.cpp
abi/src/wp/ap/win/ap_Win32App.cpp
abi/src/wp/ap/xp/ap_EditMethods.cpp
2. For most of the impexp code, this is also true. The methods which use
IEStatus are essentially doing error propagation.
3. The only place I found IEStatus used in class member variables was in
the following two importers:
abi/src/wp/impexp/xp/ie_imp_AbiWord_1.cpp
abi/src/wp/impexp/xp/ie_imp_MsWord_97.cpp
However, a grep on the field in question (m_iestatus) shows that this too is
simply being used to cache values for error propagation. AFAICT, as soon as
it gets set to anything other than IES_OK, it gets kicked up the call chain
until something can return it to the outside world.
Thus, it doesn't sound harmful (or all that destabilizing) to blend those
two datatypes there. As you said, it's just a lot of work.
>Thus, I thnik we should continue to use both, at least until something
>better comes along.
>If you violently dissagree, I am open-minded
Violent? Me? Gosh I hope not. :-)
Paul
This archive was generated by hypermail 2b25 : Fri Jan 21 2000 - 19:04:30 CST