On Thu, 22 Mar 2018 13:00:36 -0400 Cedric Bail <ced...@ddlm.me> said:
> On March 22, 2018 9:22 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> > On Thu, 22 Mar 2018 09:56:37 +0100 Jérémy Zurcher jer...@asynk.ch said:
> > > just trying to follow here and maybe clarify a bit.
> > >
> > > Of course everybody here knows about the conventions :
> > >
> > > - 0 is the success return code
> > > - anything else is an (hopefully documented) error
> > >
> > > we all know about logical shell chaining :
> > >
> > > cmd1 && cmd2 && cmd3 || cmd4
> > >
> > > but what I think I understood here is that promises chaining should be a
> > > different construction where the chaining is not dependent on the return
> > > code (success/failure) of any of the actions.
> > >
> > > { action 1 } then { action 2 } then { action 3 }
> > >
> > > it's a 'then' meaning 'after that', not an '&&' that means 'on action
> > > success'
> >
> > actually then is on success. if the promise rejects (as a failure) it won't
> > be a "then" chain that continues. that's key to promises. then here is then
> > IF the promise succeeds without failure.
>
> What are you talking about ??? There is only one callback and you get an
> Eina_Value that will be an Eina_Error in case of a rejected promise and
> something else if it was a success. The code inside the then has to decide
> what to do in all case.
that is what you should be doing:
fn(a).then fn(b).then fn(c).then print("all ok");
it will stop at b as the last thing executed if b's promise reports an error.
even you yourself said that it's reported in some languages as an exception.
that is the same as "if v.type != EINA_ERROR { ... }" inside the single then cb
we provide. the then cb is responsible for doing the if check in c. in other
langs there may be an else case for error, or an exception, but when you have
the above then, then then ... if one element reports and error the chain stops
and doesn't do the next "then" step.
> > see eio efl_io_managr.c - if stat fails on a file it rejects the promise
> > with an error. it's doing that and that is apparently correct, but an exit
> > error code is not correct doing the same thing.
>
> Is an exit code a system failure ? Is an exit code something you can do
> something with ? Which exit code value mean ENOENT ?
it is the same kind of failure as stat() returning -1. it doesn't define WHAT
the error is globally in a standard way other than "it's an error". what kind
of error it is is different exe by exe. just like efl has different error enums
and defines for apis' than libc and so on.
> > > so with v beeing the value of the promise, you do
> > >
> > > { action 1 } then { if (v!=0) return action21 else return action22 } then
> > > { if (v==0) action 3 }
> > >
> > > and with handy helpers (operator logic) like
> > >
> > > bypassOnFailure(if (v!=0) return v)
> > > bypassOnSuccess(if (v==0) return v)
> > >
> > > you can do
> > >
> > > { action1 } then { bypassOnFailure(); action2 } then { bypassOnSuccess();
> > >
> > > action3 } then { byPassOnFailure; action4 }
> > >
> > > the chaining fails on "System errors" -> Exception on some languages
> > > the logic is implemented in the futur
> > >
> > > hope I'm not in outer space.
> >
> > see efl_io_manager.c - if a stat() of a file fails (e.g. file doesn't
> > exist), the promise rejects with a error. i simply did precisely the same
> > thing with an exit code of non-zero. it's an error/failure (that was my
> > point in indicating it is in shell examples). thus it should behave the
> > same way. not doing so is inconsistent.
>
> man 1 stat vs man 2 stat
>
> Does the first one define any return value in case of error ? Does the second
manual pages for executables DON'T generally define this like function manuals.
but they do report exit codes. they always have. they have to. see my previous
email. RUN IT. makeiles are DEPENDENT on proper exit code reporting (0 is
success, anything else failure). shell scripts are dependent on it for && and
if and sh -e etc. etc. - it's a convention that has been in place for many
decades that long pre-dates even linux existing.
http://tldp.org/LDP/abs/html/exit-status.html
follow links. SHELLS define specific error codes, so shell scripts have to use
defined ones properly. non-shell executables have far more freedom. the only
thing you can absolutely depend on is 0 is success and anything else is an
error.
> one ? This are not the same things. They do not have the same documented
> behavior. There is consistency between what you are comparing in the first
> place.
because exit codes are already a documented convention ALREADY. they don't
specifically document it int he manual page because the convention is followed.
0 is success. anything else is failure. the entire shell and process etc.
execution world relies on this.
https://en.wikipedia.org/wiki/Exit_status
"The parent and the child can have an understanding about the meaning of the
exit statuses. For example, it is common programming practice for a child
process to return (exit with) zero to the parent signifying success."
"For the shell’s purposes, a command which exits with a zero exit status has
succeeded. A nonzero exit status indicates failure."
I'm not sure how many times I need to repeat myself on this. I didn't invent
this out of thin air. It's a documented defined convention. It's the same kind
of documented defined convention like stat returning -1 on failure. It's not
documented in every man page for stat, ls, cat, sed, awk grep, but they follow
the convention because it is a requirement to live in a shell world otherwise
shells will not behave properly interpreting the exit code.
what makes you push the idea that exit codes do NOT have a standard defining
what is success and what is failure.
just google "process exit code" and read page after page that says the same
thing. and in REALITY this is correct too otherwise shell scrips and makefiles
would fall over.
if you find a misbehaving process that doesn't follow this then you have to
basically catch the error and treat it as one. like:
cmd || true
that forces the statement to succeed even though it would normally appear to
fail. the exit code *IS* reported in the error value. it's the process exit
code + 1000000. normally only 0-255 is possible (-1 ends up being 255). wait()
only reports the lower 8 bis so sticking within this range is the "right thing
to do".
> Cedric
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
