1

Topic: Error handling

During my labor activity I participated both in projects using exceptions, and in projects of errors using the codes. Now I am more declined to the second approach as exceptions really often become such implicit goto, besides their usage in the multi-threaded and asynchronous code becomes a pain. On the other hand, a failure from checks of return codes too it is bad. Let's up as it would be possible to organize ideal error handling. I while invented  both approaches through additional essence - well let there will be a performance flow (ExecutionFlow) which copy has each flow. The given essence implicitly is present at a call of each function, stores call stack and an error flag. To illustrate with the pseudocode easier: int plus2 ([it is implicit ExecutionFlow executionFlow], int x) {if (x <10) return RangeError ("bla-bla"); //the Output from function and error setting executionFlow.setError (RangeError ("bla-bla")) return x + 2;//Simply output and value reset, implicitly turns around in ReturnValue <int>} void foo () {...} the Causing code: var y = foo (5); if (y.success)//check, also installs in object ReturnValue <int> and ExecutionFlow a flag checked = true int z = bar (y);//implicitly it is led int if before coercion not to check up success the program writes a stack and it is completed if (! foo ().success) print (executionFlow.stackTrace ()); var error = executionFlow.error (); print (error.message ()) return error foo ();//did not check up success, the flag was not installed, means by a call of the following function (any) there will be a stack and abnormal termination As consider has the right to life? Whether there are languages with such approach to error handling?

2

Re: Error handling

Hello, MTD, you wrote: MTD> MTD> if (! foo ().success) MTD> Still - it is impossible to write addition simply foo.success and to hammer, it is necessary to check up if, it is tracked by the compiler and that life should seemed if to be honey empty. Simply to ignore check it is necessary instead of success to cause something like foo ().IWantToSkipThisCheck

3

Re: Error handling

Meanwhile did not meet situations when I would not like to use exceptions. Therefore I consider return codes as disgusting idea. About the asynchronous code: try {const x = await something ();} catch (e) {console.warn (e);} with the multi-threaded code or with goto I too do not know What problems, any cycle or conditional statement it "implicit goto".

4

Re: Error handling

Hello, MTD, you wrote: MTD> As consider has the right to life? Whether there are languages with such approach to error handling? Depends on a surrounding. For , say, almost always works TryXxx + a conjugate method with exceptions. All remaining methods demand much more  and conduct to infernal  - it is necessary or to fence wrappers for the stranger api, or to support some styles of error handling. I very much doubt that it turns out to combine explicit check of results of performance and compactness of the code. I.e. or we search for language with the automatic machine checked preconditions, or  in  if (error) on all code.

5

Re: Error handling

Hello, MTD, you wrote: MTD> During my labor activity I participated both in projects using exceptions, and in projects of errors using the codes. Now I am more declined to the second approach as exceptions really often become such implicit goto, besides their usage in the multi-threaded and asynchronous code becomes a pain. These are two different lines of thought with absolutely various purposes and means. In case of the codes is normally branching of business logic in which result it is necessary to continue the scenario on any separate branch. In case of a real error is a handling through exceptions in which it is necessary to kill correctly application which in it is not known what state (with error record in a broad gull), or the maximum cleaning of a context of a call in case of the server application (with error record in a broad gull).

6

Re: Error handling

Hello, vsb, you wrote: vsb> About the asynchronous code: vsb> vsb> try {vsb> const x = await something (); vsb>} catch (e) {vsb> console.warn (e); vsb>} vsb> It not the asynchronous code

7

Re: Error handling

Hello, MTD, you wrote: That exceptions that the codes of errors do not solve a problem, and generate the new. If the code describes sequence of actions, provided that that all smoothly the code idle time. If something went not so it is necessary to fulfill actions which normally out of the competence of the given code and out of knowledge of the causing. Therefore any attempt to process the codes inside leads to complexity magnification, and outside to magnification kol-va abstractions. And still the code  to select different resources which someone should release and stop (if child flows or any subscriptions). According to language followed have implicitly ExecutionFlow which would define defined a policy of response on not regular situations. And through it to select resources that storage that child flows of execution. And operators which explicitly set as to react to supernumerary behavior. Both a policy and monitoring of selection of resources there to thrust, for example to fulfill no more 100 (or even in clock periods) and storages no more 10 and no more than 4 flows. value=method1 (args) or method2 (args); action1 ();//if the return code is processed by nobody that the compiler automatically does about such//{var res=action1 (); if (res && executionFlow. NoErrorAllowed &&! executionFlow. DisableThisError (here)) return executionFlow. ReturnError (here, res, "action1"...);} action2 () or action2b (); action3 () or ignore; action4 () MTD> During my labor activity I participated both in projects using exceptions, and in projects of errors using the codes. Now I am more declined to the second approach as exceptions really often become such implicit goto, besides their usage in the multi-threaded and asynchronous code becomes a pain. On the other hand, a failure from checks of return codes too it is bad. Let's up as it would be possible to organize ideal error handling. I while invented to unite both approaches through additional essence - well let there will be a performance flow (ExecutionFlow) which copy has each flow. The given essence implicitly is present at a call of each function, stores call stack and an error flag. To illustrate with the pseudocode easier: MTD> As consider has the right to life? Whether there are languages with such approach to error handling? The right to life has any approach. Erlang notably processes errors.

8

Re: Error handling

9

Re: Error handling

Hello, MTD, you wrote: vsb>> About the asynchronous code: vsb>> vsb>> try {vsb>> const x = await something (); vsb>>} catch (e) {vsb>> console.warn (e); vsb>>} vsb>> MTD> It not the asynchronous code Why it not the asynchronous? something () returns asynchronous result.

10

Re: Error handling

Hello, vsb, you wrote: vsb> Why it not the asynchronous? something () returns asynchronous result. Because you synchronously wait result. If you continued performance of other code with not locked calls yes the code would become asynchronous and it would become suddenly not clear how to work with exceptions.

11

Re: Error handling

Hello, MTD, you wrote: vsb>> Why it not the asynchronous? something () returns asynchronous result. MTD> because you synchronously wait result. Anything I do not wait.> if you continued performance of other code with not locked calls yes the code would become asynchronous and it would become suddenly not clear how to work with exceptions. It is the asynchronous code with not locked call. It gives control at once on reaching a word await.

12

Re: Error handling

Hello, vsb, you wrote: vsb> Anything I do not wait. You confuse something - await means to wait and so it for yourself in languages known to me and conducts, by the way, now we about what language speak?

13

Re: Error handling

Hello, MTD, you wrote: MTD> You confuse something - await means to wait and so it for yourself in languages known to me and conducts, by the way, now we about what language speak? await is a generation by the compiler of the finite state machine with an output from a method and clearing of a flow and an input at the termination of execution of an asynchronous method.

14

Re: Error handling

Hello, GlebZ, you wrote: GZ> await is a generation by the compiler of the finite state machine with an output from a method and clearing of a flow and an input at the termination of execution of an asynchronous method. Yes it is clear, in the resulted code synch point - obtaining  while it we do not receive on the following line we do not get. I am not right?

15

Re: Error handling

Hello, MTD, you wrote: GZ>> await is a generation by the compiler of the finite state machine with an output from a method and clearing of a flow and an input at the termination of execution of an asynchronous method. MTD> yes it is clear, in the resulted code synch point - obtaining  while it we do not receive on the following line we do not get. I am not right? Unconditionally. Procedure residual will be launched after performance asynchronously functions and in the presence of time quantum in the manager. Therefore this really asynchronous  execution.

16

Re: Error handling

Hello, GlebZ, you wrote: GZ> procedure Residual will be launched after performance asynchronously functions Here it and there is the synchronous code, yes he pretends to be asynchronous, but its essence is that. In the present asynchronous code of such explicit synch points is not present, after operation performance the output agent is caused is allows to load better the processor without wasting time on waiting.

17

Re: Error handling

Hello, MTD, you wrote: GZ>> procedure Residual will be launched after performance asynchronously functions MTD> Here it and there is the synchronous code, yes he pretends to be asynchronous, but its essence is that. All on the contrary. It is the asynchronous code which pretends to be synchronous.> in the present asynchronous code of such explicit synch points is not present, after operation performance the output agent is caused is allows to load better the processor without wasting time on waiting. It not synch point. These instructions of the code which will be fulfilled at result obtaining. With processor loading here problems are not present, the flow will be fulfilled by the following output agent. Actually the point that if in language there are convenient means for operation with the asynchronous code (in JavaScript, Kotlin, like in C# too such is) exceptions perfectly approach for operation with errors. If such means are not present, with the asynchronous code to work very inconveniently anyway.

18

Re: Error handling

Hello, MTD, you wrote: MTD> During my labor activity I participated both in projects using exceptions, and in projects of errors using the codes. Now I am more declined to the second approach as exceptions really often become such implicit goto you, I hope, anybody forces to use exceptions as implicit goto? MTD> besides their usage in the multi-threaded and asynchronous code becomes a pain. , at us like does not become. In what a pain? Task', PLinq, class Parallel - turn an exception in AggregateException and  it in causing code. Can it is not necessary to dream anything, and it is necessary to learn simply to use exceptions and a multithreading? I on this subject wrote which that: http://rsdn.org/forum/dotnet/3606700.1 the Author: MozgC Date: 18.11.09 http://rsdn.org/forum/design/4468371.1 the Author: MozgC Date: 24.10.11

19

Re: Error handling

Hello, MTD, you wrote: MTD> During my labor activity I participated both in projects using exceptions, and in projects of errors using the codes. Now I am more declined to the second approach as exceptions really often become such implicit goto, besides their usage in the multi-threaded and asynchronous code becomes a pain. On the other hand, a failure from checks of return codes too it is bad. Let's up as it would be possible to organize ideal error handling. I while invented  both approaches through additional essence - well let there will be a performance flow (ExecutionFlow) which copy has each flow. The given essence implicitly is present at a call of each function, stores call stack and an error flag. To illustrate with the pseudocode easier: MTD> As consider has the right to life? Whether there are languages with such approach to error handling? I congratulate! You invented a monad! Type Error Monad. Languages in which such are: Haskell F# OCaml Idris About first two it is assured on 100 %, about remaining - it is less, as I do not work with them. For certain there are also other languages with support of monads generally and monads of errors in particular.

20

Re: Error handling

Hello, vsb, you wrote: GZ>>> procedure Residual will be launched after performance asynchronously functions MTD>> Here it and there is the synchronous code, yes he pretends to be asynchronous, but its essence is that. vsb> All on the contrary. It is the asynchronous code which pretends to be synchronous.  this code - synchronous. That the compiler somewhere inside  it is simple a detail of implementation and no more. If I take other compiler which will create the synchronous code in this place does not change ANYTHING - neither the code, nor behavior of the program.

21

Re: Error handling

Hello, MozgC, you wrote: MC> Can it is not necessary to dream anything, and it is necessary to learn simply to use exceptions and a multithreading? Exceptions - the bad thing, irrespectively that, you are able to use to it or not. Well that is as bad, simply to distinguish the bad code with exceptions from the good code with exceptions - it is difficult. To argue on programs with exceptions - it is difficult.

22

Re: Error handling

Hello, vsb, you wrote: vsb> any cycle or conditional statement it "implicit goto". A cycle and  take an exact place of continuation of performance. And  - we do not know an exception, where we fly. Therefore cycles and  - structural operators, and exceptions and  - are not present.

23

Re: Error handling

Hello, MTD, you wrote: MTD> Let's up as it would be possible to organize ideal error handling. I while invented  both approaches through additional essence - well let there will be a performance flow (ExecutionFlow) which copy has each flow. The given essence implicitly is present at a call of each function, stores call stack and an error flag. Natural complexity is inherent in error handling and it is not so clear, as it would be possible to simplify life of the programmer seriously. Now personally I think so. The part of errors which now are rantajm-errors, should pass to a compilation stage. An example - NRE. The part of errors should become fatal and not be processed generally (stack overflow, a storage lack). The part of errors can be cut the partial functions - not an exception by a call "log (-1)", and a compilation error. Remained to process a-lja Rust - to return Result <Type> instead of Type. MTD> As consider has the right to life? Whether there are languages with such approach to error handling? As validly noted above, it is similar on error monad. So yes, somewhere it is used.

24

Re: Error handling

Hello, AlexRK, you wrote: ARK> Hello, vsb, you wrote: GZ>>>> procedure Residual will be launched after performance asynchronously functions MTD>>> Here it and there is the synchronous code, yes he pretends to be asynchronous, but its essence is that. vsb>> All on the contrary. It is the asynchronous code which pretends to be synchronous. ARK> Semanticheski this code - synchronous. That the compiler somewhere inside  it is simple a detail of implementation and no more. If I take other compiler which will create the synchronous code in this place does not change ANYTHING - neither the code, nor behavior of the program. No, it not so. The synchronous code  a flow and will do and wait, wait, wait for nothing and so the call something () then passes by next line yet does not end. Between something () and the next line other code does not put. And the asynchronous code returns control at once, other code any there, and that after a call something (), will be fulfilled separately then at once starts to be fulfilled.

25

Re: Error handling

CD> I Congratulate! You invented a monad! CD> Type Error Monad. CD> Languages in which such is: CD> CD> Haskell CD> F# CD> OCaml CD> Idris CD> CD> About first two is assured on 100 %, about remaining - it is less, as I do not work with them. CD> For certain is also other languages with support of monads generally and monads of errors in particular. And in these monads there is an implicit conversion to , how in an idea in the first post?