"Philosphical" question on "succesful" file status testing

As a follow-up to another thread and NOT expecting consensus of opinion, I
thought I would ask this question:

When is it a "good" thing to test only the first character for "0" versus
testing for specific file status codes?

(This IGNORES the entire question of any "9x" "successful" status codes like
IBM's "97")

****

The question that I would ask is when writing a program isn't it
"program-specific" whether you would want to handle NEW successful status codes
the same as old ones?

In other words, suppose you have two approaches for "successful" status code
checking today.

Approach 1:
If FS-1 = "0" *> checks first byte (character) for "0"
versus
Approach 2:
If FS-both = "00" or
FS-both = "02" or
FS-both = "04" or
FS-both = "05" or
FS-both = "07"

Now either of these could be replaced by 88-level tests (and I am not asking
about that)

The question is (then) what happens if the implementation (as an extension, new
implementor defined "0x" or the Standard) introduces a new "0?" successful
status code.

For example, (and this is QUITE contrived and I don't think it will/would ever
happen),

If the Standard introduced a "09" status code to indicate that an OPEN was
successful but the file was on a non-mass storage device. (This might be
useful information for some applications).

If seems to me that an application programmer more often than not (but NOT
universally) should check for the specific status codes that are "known" at the
time the application is created. In that way, any NEW "successful" status code
will "fall thru" (probably to error handling). It may be that the application
will NOT need changing to handle the newly available information, but it is ALSO
possible that the newly detected situation would require "new program logic".

Therefore, if I were to make a suggestion for new program development, I would
probably suggest checking BOTH bytes (but NOT just for "00") for successful I/O
status - and to make certain that "currently unknown values returned" cause
error process to be activated. This certainly would not be necessary for all
applications but MIGHT be useful for some/many.

--
Bill Klein
wmklein <at> ix.netcom.com


.

Relevant Pages

  • Re: "Philosphical" question on "succesful" file status testing
    ... suppose you have two approaches for "successful" status code ... will "fall thru" (probably to error handling). ... possible that the newly detected situation would require "new program logic". ... Bill Klein ...
    (comp.lang.cobol)
  • Job: Lamp Developer (NYC based media company)
    ... Experienced LAMP Applications Developer ... resume, links to successful projects, and a code sample (100 or more ... development-engineering environment, assisting in the architectural ...
    (comp.lang.php)
  • Re: Telephone security - is there a competent UK bank?
    ... >>million people are blacklisted, which is complete bollocks. ... "There will also be a record of all your past and present applications ... for loans and credit..." ... were successful - if the credit a/c subsequently appears on the file then ...
    (uk.finance)
  • Re: Re: C# programmer wants to learn assembly?? plz help
    ... are the Linux Applications written with NASM? ... Where are all these FASM applications, if FASM is so successful? ... language isn't exactly the proof that an assembler is popular or not. ...
    (alt.lang.asm)
  • Re: .NET 3.0 Final
    ... better applications quicker and for less cost your clients will start asking what is going on. ... So far I haven't seen any definitive study saying that developing in Delphi for .Net instead of Delphi for Win32 produces better applications more quickly and costs the consumer less money. ... Now, I've modified that question to be - "Name one, successful, commercial application that is written exclusively using .Net." ...
    (borland.public.delphi.non-technical)