recode

[Pawel Krawczyk]

On Tue, Sep 21, 1999 at 09:29:19PM -0400, François Pinard wrote:

> For `librecode', the user may set the library so it issues the diagnostic
> itself and aborts in case of problem.  This capability is quite convenient
> for most cases.  Also, in another mode, it does as you suggest, and merely
> return error codes, so the library user gets fuller control about it.
> But once again, I would rather not force library users to necessarily
> check all return codes themselves, with no other choices.  In most simple
> applications, letting the library diagnose and abort is easier, and welcome.

Well, I don't think it's a big problem for developers using
librecode. When you use an external call in a program, you'd rather
expect that it may fail and prepare your code for that possibility.
I'm trying to use librecode for tin newsreader charset conversions.
In this case I'm almost sure that the conversion will fail at some types
of strange or badly declared text, which is common in Usenet. What's
more important there can be several types of failures, ones that
inhibit conversion at all, others that only require to skip an
offending part of text.

But the recode task structures gives access to this type of information
quite easily, so this is not a problem. Problem is that actually I'm
improving some third party program using third party library. In this
particular case the program_name is unique for recode, but if tin also
used this symbol for some other purposes? 

Instead of having the program_name symbol in the librecode, I'd rather
make another library, say librecode_simple, which would contain procedures
for simple programs using auto-abort feature you mention.

-- 
Pawel Krawczyk, CETI internet, Krakow. http://ceti.pl/~kravietz/