Re: #include ap_EditMethods.cpp


Subject: Re: #include ap_EditMethods.cpp
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Thu Jan 20 2000 - 00:41:32 CST


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 19 Jan 2000, Paul Rohr wrote:

> At 12:01 AM 1/20/00 -0600, you wrote:
> >The function is called toErrorCode(...), and will eventually be
> >overloaded. It currently takes arguments of type IEStatus and transforms
> >them into error codes. It is cross-platform, and not neccessarily abiword
> >specific. I am not sure what XAP is (although my bet is that it is
> >cross-abisuite), so I don't know wether it is or not. Hope this helps
>
> OK. Now I get it.
>
> I think if we do things right, you shouldn't need this function at all.
> Jeff originally defined a bunch of IEStatus codes which are local to the
> following app-specific subtree:
>
> abi/src/wp/impexp/ie_types.h
>
> Now it looks like you're mapping them to a new set of equivalent
> UT_ErrorCode values which can be used in cross-app (XAP) code:
>
> abi/src/af/util/xp/ut_types.h
>
> It's not clear to me that we need two discrete overlapping sets of
> Error/Status codes here, particularly since the IEStatus set seems like it'd
> be pretty useful for other applications. However, you've been in that code
> a lot more recently than I have -- do you know of any reason to maintain the
> distinction?

The reason that I wanted to use error codes is that they fit better into
overall error handling. There are several reasons for this. first, there
are more error codes than just in file i/o, which is all that there are
IEStatus codes for. (There aren't even enough status codes for all the
i/o errors.) Second, using errorcodes allows for a function that has some
calls returning IEStatus, and some returning errorcodes. I think that
both of the functions I've worked with that used IEStatus have been like
this. In short, IEStatus just is not as flexible as UT_ErrorCode.
Just to clear up any misunderstanding, I did not create error codes, even
though I have written most of the code that handles them (I think). There
were already two defined when I started about 10 days ago.

>
> If not, I suspect we could just convert the impexp APIs to use UT_ErrorCode
> throughout, thus removing the need for a conversion function. While you're
> in there making the change, two quick suggestions:
>
> 1. Our default coding style for #define constants is usually:
>
> UT_ALL_CAPS_STYLE // a public constant
> ut_ALL_CAPS_STYLE // a private constant
>
> Where the only variation in capitalization is the lowercase prefix for stuff
> which isn't intended for use outside that module.

I used lower case because the creator of UT_ErrorCode had. If that should
change, I could do that fairly easily.

>
> 2. I'm tempted to keep things terse and just call it UT_Error instead, but
> that's just me.
See above.
>
> Paul
>
>

           
                                     sam th
                                     sytobinh@uchicago.edu
                                        
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4hq4dt+kM0Mq9M/wRAjKaAKDIBEU9EMkuBeE/DWtfUxAxvGxNwQCgzB3w
/A/WuCXo7puO5UM2XI7R9Rg=
=c3vc
-----END PGP SIGNATURE-----



This archive was generated by hypermail 2b25 : Thu Jan 20 2000 - 00:41:35 CST