1. error codes in returns
- Posted by useless Sep 10, 2009
- 1321 views
Is there a global format in v4 for how error msgs should be returned from tasks or includes?
Some return 0 , some -1, some return text, some return a OS error code. What's preferable when adding error returns or running states?
If you have an include that does dvd writing, how should it task_msg or return{} back that the user prematurely ejected the disk? If your internet connection drops, how should htte.e let the main code of the app know? If the whoziwhatsis on the parallel port lost it's thingamabob, what form should the error be returned in?
What format should these codes take? Not what these specific codes should be, but what is the Eu v4 global standard format for error msgs? It's sorta important so others can use your whoziwhatsis_driver.e in their application. If the standard is blork[2] is always a human readable text sequence, then everyone will know, no matter what error is thrown by whatever include they get from the user contribs, blork[2] is always a human readable text sequence.
Please hammer this out amongst yourselves and let me know what you decide.
useless
2. Re: error codes in returns
- Posted by alanjohnoxley Sep 10, 2009
- 1321 views
As a standard, how about a sequence of 2, first element is numeric (0 indicates OK) and the second element is text containing details. similar to our
value()
function
(now ducking for cover ;)
3. Re: error codes in returns
- Posted by mattlewis (admin) Sep 10, 2009
- 1280 views
I don't think there is such a thing. It's really dependent upon the context.
- There are several areas where a sequence is normal operation, and an atom denotes an error or other condition (gets, regexes). I've used this method in some of my own code (eusql).
- Some simply return a zero or -1 to indicate failure (routine_id, define_c_*, open) and a positive number to indicate success.
- Others use a sequence with the error code and result as separate elements (value).
I doubt there will ever be a global standard for error status.
Matt
4. Re: error codes in returns
- Posted by alanjohnoxley Sep 10, 2009
- 1284 views
I suppose we could just add a comment in the top of our included library, like "All functions will return (whatever) by default, unless specifically mentioned otherwise." Pity... would have been nice to have a standard but it seems the scope is too broad. Not that we have too much chance of everyone agreeing anyway, not to mention who would retrofit existing common libraries and the offence some may take to that.
5. Re: error codes in returns
- Posted by jeremy (admin) Sep 10, 2009
- 1292 views
On every function in the standard library, we do include a Returns section. Each function has this. For example, Regex Find/Match.
Jeremy
6. Re: error codes in returns
- Posted by useless Sep 10, 2009
- 1288 views
Yes, but for new stuff in v4?
For instance, in http.e, i added several returns for errors last week, and now i find two problems (mentioned previously when downloading certain files) that are actually recoverable and deal-with-able using the task msging i am writing, but unrecoverable without task msging. For that matter, using task msging could reduce the size of http.e just by eliminating the commented out get_http_with_cookie() code. If i make up my own error format, and make the http.e return error match the task msg error umm then what? And what about all the noise that's going to happen on this forum when 3 people don't like 3 different things about the form i choose? To complicate things, i do not want the error format to be the same as a task msg that says "oops, the website wants a password, where is it?" because that's not an error.
Do i just wing it anyhow? Or what?
useless
7. Re: error codes in returns
- Posted by mattlewis (admin) Sep 10, 2009
- 1281 views
Do i just wing it anyhow? Or what?
You seem to have a pretty good handle on the various types of situations that your particular API needs to deal with. The way things typically work is that you'd come up with some system to deal with it, show it to others, and it would grow and evolve from there. Probably, others will have some drastically different use cases than you will, and some aspects will need to be modified to compromise between multiple ways of using the API.
I doubt anyone not familiar with dealing with this particular issue (downloading web content) will be able to say much about that particular case. What you probably need to do is to figure out the various ways that you need to communicate and make sure that the infrastructure for doing so makes sense for you (the task messaging stuff in this case, I suppose).
Then you need to document how to use it so that others, not involved in the development, and maybe not even familiar with that sort of task, can figure it out.
Matt
8. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1271 views
Other programming languages offer exceptions for these use cases. In Eu you have to use some workaround: Setting an errno-like variable or return error codes that you need to pass up the call stack yourself. IMHO both workarounds suck. As usual, Eu's simplicity is fiction: Eu itself is simpler than other langauges because it lacks language features, but code written in Eu is more complex than necessary due to the missing language features. The day Eu contains the missing stuff its simplicity is gone too. That's not a bad thing, but the developers could acknowledge this.
9. Re: error codes in returns
- Posted by jacques_desch Sep 11, 2009
- 1229 views
my prefered way to this is like windows win32 api does in most cases. Return a boolean and call GetLastError() to get the error number and there is another function to get text for that error.
I think libraries should word that way.
public function GetLastError() return last library error code
public function ErrorText(integer error_code) return text for that error.
Jacques
10. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1210 views
Using both return values and "errno" is even worse IMHO. If you have to check for an error after each call anyway, why not return error codes directly? Additionally "errno" has the problem that somehow somebody needs to reset it.
11. Re: error codes in returns
- Posted by euphoric (admin) Sep 11, 2009
- 1341 views
The day Eu contains the missing stuff its simplicity is gone too.
I think simplicity gets confused with ease-of-use. Euphoria is not simple, but it is easy to use. Good for beginners, good for professionals.
We could add something complex to Euphoria and not take away from its base ease-of-use.
IOW, if we add exceptions, that doesn't make Euphoria any less easy-to-use by the fact that the user doesn't need to use exceptions. It does add complexity for when it's desired, but that just makes Euphoria more powerful.
I have a system where I return a two-element sequence from functions, { SUCCESS_CODE, RESULT }, where SUCCESS_CODE is a boolean representing the success or fail of the function, and RESULT is the error message if it failed, or actual result of the function if successful. I don't know that this is any better than the current almost-standard method of returning an atom upon fail. I think somebody convinced me it's not. But I've used it successfully for a while. 
12. Re: error codes in returns
- Posted by DerekParnell (admin) Sep 11, 2009
- 1211 views
Other programming languages offer exceptions for these use cases. In Eu you have to use some workaround: Setting an errno-like variable or return error codes that you need to pass up the call stack yourself. IMHO both workarounds suck.
- Not all programming languages have implemented exceptions.
- We plan to have exceptions in Euphoria.
As usual, Eu's simplicity is fiction: Eu itself is simpler than other langauges because it lacks language features, but code written in Eu is more complex than necessary due to the missing language features. The day Eu contains the missing stuff its simplicity is gone too. That's not a bad thing, but the developers could acknowledge this.
As usual, Critic's generalizations are fiction.
We have put a lot of effort in to ensuring that Euphoria is simple to use, by putting in a lot of under-the-hood complexity. One of our goals is to uphold the original design philosophy of rapid development.
The journey has not ended yet. There are still further simplifications that will be made, and this will involve making the internals more complex.
13. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1220 views
I think simplicity gets confused with ease-of-use. Euphoria is not simple, but it is easy to use. Good for beginners, good for professionals.
Right now Eu is simple, but at least some parts of it are not easy to use. It's C interface comes to mind. If all the features have been added, perhaps it is easy to use.
We could add something complex to Euphoria and not take away from its base ease-of-use.
I've heard that before. C comes to mind.
IOW, if we add exceptions, that doesn't make Euphoria any less easy-to-use by the fact that the user doesn't need to use exceptions. It does add complexity for when it's desired, but that just makes Euphoria more powerful.
Yeah and if one wants to use a library that uses exceptions one has to learn how to deal with them. More features inevitably mean more to learn. Not that exceptions are a bad thing, though.
14. Re: error codes in returns
- Posted by mattlewis (admin) Sep 11, 2009
- 1364 views
Not that exceptions are a bad thing, though.
They're not necessarily a good thing, either. Nor are they always easier to use. See, for example:
- Cleaner, more elegant, and wrong
- Cleaner, more elegant, and harder to recognize
- Your exception handler can encounter an exception
Matt
15. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1189 views
- Not all programming languages have implemented exceptions.
- We plan to have exceptions in Euphoria.
I know. It's good that they are planned.
We have put a lot of effort in to ensuring that Euphoria is simple to use, by putting in a lot of under-the-hood complexity.
Well, before I mentioned it, your switch statement design hardly was "simple to use". It was just copied blindly from C. You put a lot of implementation effort in Eu, but I cannot see much design effort. I think it was one of the core developers who had never even heard of implicit fallthrough being bug prone. Maybe it's a good idea for some of the developers to do more programming language research. That's what I mean by design effort. Now go ahead and bowdlerise me.
16. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1210 views
They're not necessarily a good thing, either. Nor are they always easier to use.
Yeah, but since they are already planned I fail to see the need to convince you that they are better in most cases.
17. Re: error codes in returns
- Posted by jimcbrown (admin) Sep 11, 2009
- 1174 views
Well, before I mentioned it, your switch statement design hardly was "simple to use". It was just copied blindly from C. You put a lot of implementation effort in Eu, but I cannot see much design effort.
Well, there were certainly many arguments and long discussions before that behavior was finally chosen.
18. Re: error codes in returns
- Posted by jeremy (admin) Sep 11, 2009
- 1104 views
Well, before I mentioned it, your switch statement design hardly was "simple to use". It was just copied blindly from C.
Ha! That's pretty funny. Did you not see any of the great discussions before you commented on switch? If I recall, it was not you who questioned switch once it was implemented, you just jumped in. Anyway, with switch the developer team, after much discussion, was split down the middle, so what did we do? Continuing our design stage, we implemented one method and began to use it to test the waters on how it was going to work out. Sometimes the best design comes with a little use of a design. Have you heard of of prototyping as a stage of design?
Jeremy
19. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1147 views
Ha! That's pretty funny. Did you not see any of the great discussions before you commented on switch?
No, I honestly didn't. I started the thread back then, you can check yourself. I am not aware of any discussions about switch before I created that thread.
Have you heard of of prototyping as a stage of design?
You mean you prototyped a language feature that has been copied over from C, even though it obviously has been designed better in Ada, Pascal and Basic? Fine excuse!
20. Re: error codes in returns
- Posted by mattlewis (admin) Sep 11, 2009
- 1186 views
Ha! That's pretty funny. Did you not see any of the great discussions before you commented on switch?
No, I honestly didn't. I started the thread back then, you can check yourself. I am not aware of any discussions about switch before I created that thread.
You may have started the discussion on the forum, but there had been a lot of talk on the dev list, at least, prior to that.
Matt
21. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1305 views
You may have started the discussion on the forum, but there had been a lot of talk on the dev list, at least, prior to that.
Yeah, but I guess most Eu users didn't notice and thus didn't participate. Anyway, things changed after the discussion that I started. So personally I come to the conclusion:
- The devs discussed and came up with a poor switch statement design.
- The rest of the community discussed and things improved.
- My presence here is important.
Please discuss upcoming language features in this forum.
22. Re: error codes in returns
- Posted by euphoric (admin) Sep 11, 2009
- 1174 views
Yeah, but since [exceptions] are already planned I fail to see the need to convince you that they are better in most cases.
planned != implemented
And there's certainly no guarantee they will be.
It will be only be after much discussion; that I can guarantee.
23. Re: error codes in returns
- Posted by DerekParnell (admin) Sep 11, 2009
- 1153 views
Well, before I mentioned it, your switch statement design hardly was "simple to use". It was just copied blindly from C.
Let me see if I understand you ... you believe it was your effort and persuasive argument that caused the current switch design? And all the hours of discussion before you joined in the discussion were for nothing?
You put a lot of implementation effort in Eu, but I cannot see much design effort.
I believe you. I'm sure you do follow all the discussion, arguments, prototyping, etc... that the developers do outside this forum. However, just because you can't see it, it doesn't mean its not happening.
I think it was [deleted] who had [deleted] of implicit fallthrough being [deleted]. Maybe it's a [deleted] idea for some of the [deleted] to do more [deleted] research. That's what I mean by [deleted]. Now go ahead and bowdlerise (sic) me.
Done.
24. Re: error codes in returns
- Posted by Critic Sep 11, 2009
- 1136 views
Let me see if I understand you ... you believe it was your effort and persuasive argument that caused the current switch design?
No, I believe my post was the trigger to vastly improve the design.
And all the hours of discussion before you joined in the discussion were for nothing?
No, they've lead to the first (poor) design.
I believe you. I'm sure you do follow all the discussion, arguments, prototyping, etc... that the developers do outside this forum. However, just because you can't see it, it doesn't mean its not happening.
No, of course I do not follow these things. And I think most Eu users do not either. So why not discuss these things in this forum?
Forked into: switch design
Forked into: Forum Categories
