OS APIs without error codes

[gravaera]

Yo:

Wouldn't it be easier to simply use a bitmask to return multiple error conditions? It seems like it'd work under most scenarios pretty well, perhaps there are some scenarios were you would have to worry about handling more than 32 or 64 error conditions but I can't imagine there would be many. At any rate in such scenarios calling several syscalls to resolve the error would definitely be a huge performance hit as well.

In practice, no: if a syscall passes through several "hurdles" at which an error can occur, it normally stops and returns error at the first one, because proceeding with a shaky state into the second hurdle is just likely to cause another error, or produce suboptimal results.

If the syscall is of such a nature that it can be completed sanely with one or more unusual flags occuring then the API would normally just provide a "FORCE_OPERATION" flag that the app explicitly passes to bypass a certain hurdle if it has knowledge of the ramifications. In practice, since continuing with unstable state into a syscall past an error point would produce more errors, and possibly corrupt system state, the kernel usually just returns an error code for the first encountered error and then leaves the onus on the application to rectify it and call in again, etc.

An error bitfield would end up unintentionally just becoming a single-error value since it will rarely ever have more than one bit set on return.

--Peace out
gravaera

[Solar]

I like your idea. Especially since that would define the possible error returns per API, not in a huge list that is specific for each OS and version.

And for showing error reasons to users, I think returning a text string is quite adequate, and only requires a printf or similar to decode.

That's just too much. How can anyone take this guy seriously? If that's not either trolling or complete retardedness, what is?

PS: For those wondering why I throw up my hands in exasperation... given the C standard library's "errno" mechanism, the list of possible error returns is well-defined per API call, and the the perror() and strerror() functions turn an errno value into a (localized!) error description.

Not that the "errno" mechanism is perfect; it has a couple of problems itself (especially in the realm of multithreading).

[Cognition]

Yo:

In practice, no: if a syscall passes through several "hurdles" at which an error can occur, it normally stops and returns error at the first one, because proceeding with a shaky state into the second hurdle is just likely to cause another error, or produce suboptimal results.

If the syscall is of such a nature that it can be completed sanely with one or more unusual flags occuring then the API would normally just provide a "FORCE_OPERATION" flag that the app explicitly passes to bypass a certain hurdle if it has knowledge of the ramifications. In practice, since continuing with unstable state into a syscall past an error point would produce more errors, and possibly corrupt system state, the kernel usually just returns an error code for the first encountered error and then leaves the onus on the application to rectify it and call in again, etc.

An error bitfield would end up unintentionally just becoming a single-error value since it will rarely ever have more than one bit set on return.

--Peace out
gravaera

I'm not suggesting the whole multiple return value thing is necessarily a great thing to go after in the first place. Just that if you wanted to do it, this would be one of the simplest ways to return a number of error conditions without querying the kernel multiple times or having to form a list somewhere.

[rdos]

PS: For those wondering why I throw up my hands in exasperation... given the C standard library's "errno" mechanism, the list of possible error returns is well-defined per API call, and the the perror() and strerror() functions turn an errno value into a (localized!) error description.

FYI, the standard C errno mechanism can be implemented with a syscall API that doesn't return error code information. I know because I've done it.

Not that the "errno" mechanism is perfect; it has a couple of problems itself (especially in the realm of multithreading).

Yes, the multithreaded errno implementation have to rely on things like thread local storage.

[Yoda]

FYI, the standard C errno mechanism can be implemented with a syscall API that doesn't return error code information. I know because I've done it.

There is a Russian joke about a priority in surgery. A professor claimed that he made a unique surgical operation: tonsillectomy. Others wondered, - this surgical procedure is 3 thousands years old! But not via rectum!! - he replied

[piranha]

FYI, the standard C errno mechanism can be implemented with a syscall API that doesn't return error code information. I know because I've done it.

Uh huh. It doesn't return any error information? So, how do you know what the error is? Do you guess?

I believe that you're talking about using your superfluous kernel-polling error info API (which I just don't understand why you would do such a thing. Even if you're the only one who is writing programs for your OS, it just seems silly. Please, provide us with a real example, discuss exactly why it is better in an objective way. So far, I haven't seen that. If you want to post your design decisions here, expect people to respond critically to them, and if this many people disagree that it is a good idea, maybe you're wrong? Or is that even possible?)

Anyway, given a function (say, open) that can return the following errors (of course there are more, this is simplified):

• access denied
  no such file
  invalid argument
  bad path
  interrupted by signal
  IO error

Go ahead, write the user space error handling API for this exactly how you envision to be "perfect".

-JL

[bluemoon]

Code: Select all

int syscall_get_errorno() {
  return FeatureNotSupported;
}

[qw]

Looks a lot like the Epimenides paradox.

[miker00lz]

i try to keep an open mind, but this whole thread is kind of stupid. why would you ever possibly want to do that? if you're just returning a boolean, you ALREADY are returning a value anyway so it might as well be a specific value telling the application what the problem was!

and about checking various printer states before making a print call, what if something changes between the time you asked and the time you print, resulting in a failed print call without you knowing why.

brilliant!

[Brendan]

Hi,

Best kernel syscall ever is in BeOS anyway.

Code: Select all

// Returns:
//   0 = computer has been sent "wake on LAN" packet
//   1 = computer is booting
//   2 = computer is on
//   3 = computer is preparing for shut down
//   4 = computer is in the "soft off" state (waiting for "wake on LAN")
//   5 = computer is off (unable to respond to "wake on LAN")

int _kern_is_computer_on(machine_ID)
{
   return state_of_each_computer_in_the_cluster[machine_ID];
}

Cheers,

Brendan

[rdos]

FYI, the standard C errno mechanism can be implemented with a syscall API that doesn't return error code information. I know because I've done it.

Uh huh. It doesn't return any error information? So, how do you know what the error is? Do you guess?

I believe that you're talking about using your superfluous kernel-polling error info API (which I just don't understand why you would do such a thing. Even if you're the only one who is writing programs for your OS, it just seems silly. Please, provide us with a real example, discuss exactly why it is better in an objective way. So far, I haven't seen that. If you want to post your design decisions here, expect people to respond critically to them, and if this many people disagree that it is a good idea, maybe you're wrong? Or is that even possible?)

Anyway, given a function (say, open) that can return the following errors (of course there are more, this is simplified):

• access denied
  no such file
  invalid argument
  bad path
  interrupted by signal
  IO error

Go ahead, write the user space error handling API for this exactly how you envision to be "perfect".

-JL

Code: Select all

    int handle;

   handle = RdosOpenFile(path);
   if (handle == 0)
       setterrno(FILE_NOT_FOUND);

Works just fine. There is no other relevant return status.

1. Syscalls cannot be interrupted (interrupted by signal not relevant)
2. IO-errors are not returned to application (they are fatal)
3. Invalid parameter doesn't exist (other than at the C level)
4. Access denied cannot be returned as RDOS doesn't support access control

[piranha]

Trouble is, you started this thread with:

Traditional APIs (like DOS, Windows and *nix) are cluttered with error-codes, but is this really necesary? Isn't error-codes just a bagage from non-object oriented designs that are not really necesary?

Your OS may be perfect and you may be a perfect programmer and make it impossible for someone to supply an input that is a bad path (part of the path isn't a directory, etc, any other errors of which there will be a multitude for a lot of syscalls). But since you started this thread talking about API's in general, all the arguments you just made that discarded the error codes that I set forth in my challenge are then invalid. The point was to write error code handling for that challenge for a general OS, where all those errors are not fatal, can happen, and need to be handled by the application.

-JL

[rdos]

Your OS may be perfect and you may be a perfect programmer and make it impossible for someone to supply an input that is a bad path (part of the path isn't a directory, etc, any other errors of which there will be a multitude for a lot of syscalls).

FILE_NOT_FOUND covers a bad path as well. Naturally, the FS traversing code will notice that there is no match for part of the pathname and abort the search, but it won't set an error code. It would just abort with CY set. There is no reason to separate bad path from file not found, as they are essentially the same thing.

But since you started this thread talking about API's in general, all the arguments you just made that discarded the error codes that I set forth in my challenge are then invalid.

I don't discard error codes. I never produce them, since I don't think lists of error codes are compatible with an object oriented design. They violate the encapsulation requirement, because as soon as you add a new global error code, all your error code processing code might become broken since you don't handle that case. That's why I don't support error codes.

The point was to write error code handling for that challenge for a general OS, where all those errors are not fatal, can happen, and need to be handled by the application.

Applications shouldn't handle OS issues. The OS should do it's best to perform syscalls, and when this fails, these failures are fatal and there is nothing the application can do about it provided that the application checked relevant preconditions. That is my design concept in regard to this issue. So if an application passes an invalid path or non-existent file to openfile, it has violated the preconditions and should be rewritten to make sure it produces valid paths and checks that files it assume to exist also exists.

My error handling philosophy is that error handling should be localized, and not globalized, which means that errors should be handled where they are produced, and not propagated for ever to higher levels to be handled by a monster error handler. With localized error handling, there is no need for global error codes.

[rdos]

@rdos
How do you go from carry flag to int handle again?

Pseudocode for RdosOpenFile:

Code: Select all

; file handle is returned in ebx for 32-bit memory model

RdosOpenFile    Macro
    DoSyscall ; returns handle in bx
    jc failed

ok:
    movzx ebx,bx
    jmp done

failed:
    xor ebx,ebx

done:
                     Endm

[Solar]

I don't discard error codes. I never produce them, since I don't think lists of error codes are compatible with an object oriented design.

My error handling philosophy is that error handling should be localized, and not globalized, which means that errors should be handled where they are produced, and not propagated for ever to higher levels to be handled by a monster error handler.

To wit: Every OO language I know uses exceptions, for the very reason that errors should not be handled at the point they occur (e.g. the filesystem), but at the point where something can be done about them (the application).

Applications shouldn't handle OS issues. The OS should do it's best to perform syscalls, and when this fails, these failures are fatal and there is nothing the application can do about it provided that the application checked relevant preconditions.

That is your opinion. It might even work for RDOS. In the general case, you'd want to have multitasking, and in such an environment the above design is BS.

Can we close this?