OSDev.org

Solar is on my ignore-list unless he writes something really interesting. Above post ignored...

Doesn't make much difference, when you're blithely ignoring the "interesting" parts just as well, huh?

Anyway, that post was not for your benefit.

[off topic]
Since Solar changed his post, I feel I need to answer on this one (not because it is interesting, but because it spreads misinformation)

Solar wrote:You didn't "add choices". You made a claim, we shot it down, and you're now trying to weazel out of it.

Correction: Lots of people didn't understand the concept, and posted incorrect code, yourself included. You cannot "shoot" something down unless you understand it.
[/off topic]

*Sigh*

Everybody here does understand your concept. Nobody here - with the noteable exception of your person - thinks that it's a good idea. And because you have a personality deficit that makes you incapable of ever admitting that you've been chasing wild geese, and rather think that you're the genius and everybody else is wrong you're trying to spin it off into a discussion about who ever could write the more convoluted source example.

I'm not playing that game anymore.

You know the story about the motorist listening to the traffic announcement about "a person driving against the traffic"?

"One? There are hundreds of them!"

That motorist is you. All I am still doing here is trying to keep others from following your example. End of communication.

My last post in this topic. When you return boolean status, you are doing less than returning error code. Even using error code oriented API, you can just compare the error code to OK value and proceed as with your boolean flag oriented API.

i'm having a problem with the part where returning an error code turns into a error pop-up for the user...

there is NO reason the error codes can't just be discarded, and carry on just like there wasn't any. but if I wanted to use it, it should be there - as an option to the programmer.

A little contribution to the discussion: an alternative to error codes are exceptions, but that's probably a lot less efficient.

Griwes wrote:My last post in this topic. When you return boolean status, you are doing less than returning error code. Even using error code oriented API, you can just compare the error code to OK value and proceed as with your boolean flag oriented API.

That is true, but if you use the API in that way, why bother with returning the error code in the API when nothing uses it?

The only other valid reason I can come up with for keeping the error codes, if you don't use them, is POSIX compliance. OTOH, a possible remedy would be to return the most likely error code to POSIX.

I agree with what the original poster is trying to accomplish - to remove the need to check errors after every call.

Errors are errors, they should occur outside of the norm, and you shouldn't have to do: It just makes code messy and ugly. You could use an exception based approach - that is register allow a program to optionally register an error callback function, then if an error code is generated in the kernel, make the user thread call the error callback function if one is registered.

Then inside the error callback function, the programmer can choose what to do (check the error messages and either ignore it or throw the relevant exception if the language supports it).

rdos wrote:That is true, but if you use the API in that way, why bother with returning the error code in the API when nothing uses it?

If you are the only person who ever writes application programs for your OS, then you might have a point. But if you expect other people to program for it then some might choose to use the error code as just a Boolean flag whist others might choose to use it to handle the error. Even a single programmer might sometimes want a simple failure indication but at other times might want to process the failure.

So, if you have a half-arsed OS that only you will ever use, then you are correct. But most people writing an OS will want to include just a little flexibility in it to suit different programmers.

iansjack wrote:If you are the only person who ever writes application programs for your OS, then you might have a point. But if you expect other people to program for it then some might choose to use the error code as just a Boolean flag whist others might choose to use it to handle the error. Even a single programmer might sometimes want a simple failure indication but at other times might want to process the failure.

So, if you have a half-arsed OS that only you will ever use, then you are correct. But most people writing an OS will want to include just a little flexibility in it to suit different programmers.

Well, I find it likely that I would be the only major player that will write applications for my OS, but I might be wrong.

Anyway, an error-code less API also means that you optimize the API to have functions that are well defined and have well-defined error causes. This is done in multiple ways, like not allowing structures to be passed to kernel, and not overloading file operations with multiple unrelated things like sockets and pipes. In fact, functions that typically have multiple possible error returns must be implemented in an user level library, and then anybody is free to use a class-based interface, or a more traditional C/error-code based one. Even file handle sharing among processes must be implemented in clib, since RDOS has no way to open or redirect a file handle to console input, and does not support inheriting handles in a child process. The file API can only be used with files in the current process. Therefore, at the C-lib level, the classical error codes in the file-IO and stream interface are supported, they are just not supported when the raw file API is used. So for file-IO, users already have a choice. Use the standard C library functions.

rdos wrote: When I worked a lot on the Windows API, ... I'd wish I could have traced the syscall into kernel to see why it failed.

K, so you want to propose that kernels allow you to hook into them with state dumps or status checking functions? No problem -- this can easily be implemented alongside a conventional error-code returning API in your kernel. There's still no need to try to debunk error code return values

rdos wrote:Well, I find it likely that I would be the only major player that will write applications for my OS, but I might be wrong.

OK, I appreciate where you are coming from (and I don't think you are wrong).

As you are the only person who will ever use or program your OS you are, of course, free to make whatever design decisions you like (however poor I may think they are). But I don't understand why we are wasting our time discussing something that is of no importance to all but one of us.

I'm out of here.

Solar wrote:All I am still doing here is trying to keep others from following your example. End of communication.

The things are so obvious, that I even didn't want to enter the discussion. I can only wonder why it is not obvious for rdos. So there is no need for keeping others from this design error.
1. That two approaches are logically almost equivalent. The primary difference is that emulation of error codes is less efficient since it requires a call to kernel for each query instead of a simple comparison or even a table lookup.
2. "Almost" in the previous statement means that in query design the situation may change (while the thread is thinking what's happened) and chasing the changing situation may make the program slightly crazy. In error codes design this situation is excluded.
3. Nothing prevents the parallel implementation of both designs for that "originally thinking" programmers. But i'd prefer not to have that query mechanism at all, cause it may tempt a programmer to use ineffective code.

rdos wrote:

Griwes wrote:My last post in this topic. When you return boolean status, you are doing less than returning error code. Even using error code oriented API, you can just compare the error code to OK value and proceed as with your boolean flag oriented API.

That is true, but if you use the API in that way, why bother with returning the error code in the API when nothing uses it?

The only other valid reason I can come up with for keeping the error codes, if you don't use them, is POSIX compliance. OTOH, a possible remedy would be to return the most likely error code to POSIX.

No, POSIX is sh*t, generally. There is exactly one word, which's meaning you fail to understand, and that word has already been mentioned: "flexibility".

And in the start you generalized. The topic wasn't "I'm thinking about implementing API without error codes in my OS that no-one will ever write programs for", but you've implied that "error-codeless APIs are better in every possible case". Here, again: check the definition of word "flexible". And, more important: don't imply that solutions that work for RDOS will always work and are far superior - because you are just wrong. And yes, you are implying that they are superior, you do it in every thread lately.