26

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> Hello, Stanislaw K, you wrote: SK>> Prefers to check conditions beforehand. S> that means beforehand? You checked up,  were. While caused - money already is not present. Preliminary check is necessary irrespective of dispute the codes \exceptions.

27

Re: Again about business process exceptions (2017)

Hello, scf, you wrote: scf> Now the judgement tends "the codes of errors", but is active  both approaches. Where , Bills? To us are necessary !

28

Re: Again about business process exceptions (2017)

Hello, gandjustas, you wrote: G> Preliminary check is necessary irrespective of dispute the codes \exceptions. Somewhere at this forum already considered what to try to fulfill at once operation without preliminary checks and is easier and cheaper. As the result of such check can become irrelevant almost instantly.

29

Re: Again about business process exceptions (2017)

Hello, TG, you wrote: TG> Hello, gandjustas, you wrote: G>> Preliminary check is necessary irrespective of dispute the codes \exceptions. TG> Somewhere at this forum already considered what to try to fulfill at once operation without preliminary checks and is easier and cheaper. As the result of such check can become irrelevant almost instantly. To begin with esteem: https://www.artlebedev.ru/best/ui/humaneness/ http://bureau.ru/bb/soviet/20150714/ http://medvedism.ru/blog/all/birman-ui- … -course-1/ include a brain Further. Here there is a primitive program, in it only an account number of the sender, the account number of the receiver and the button to "send". Also there are two variants: 1) Checks to do at the moment of sending and if something happens to throw to the user an error. 2) checks to do at the moment of discovery of the program and simply to do the button to "send" to the inactive. In 99 % of cases the second variant is more pertinent. In this case operation will not be fulfilled if preconditions are not fulfilled. It will be finite the second variant for the programmer more difficult, but to you money eventually pays that you overcame these complexities. It becomes finite in the second variant result of check "almost instantly" the irrelevant. But you can staticize it "almost instantly" also. And considering that remittance "almost instantly" in real life does not happen, it is quite possible to pick up a sufficient interval for actualization. . The most expensive resource which you can spare or spend - time of the user. It is directly connected to expenditures on maintenance and with a gain if the program is on sale.

30

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> Why you consider, what transfer of means from the empty account than that differs from discovery of a nonexistent file? For the user of the program differs, and Exception or to return return code it is a trick () and tastes of the developer, a command or the one who in it makes decisions.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

31

Re: Again about business process exceptions (2017)

Hello, gandjustas, you wrote: G> Hello, TG, you wrote: TG>> Hello, gandjustas, you wrote: G>>> Preliminary check is necessary irrespective of dispute the codes \exceptions. TG>> Somewhere at this forum already considered what to try to fulfill at once operation without preliminary checks and is easier and cheaper. As the result of such check can become irrelevant almost instantly. G> under "preliminary checks" I mean: whether there are enough money for the account, whether the account and so forth is blocked. I.e. all that is "on that side" functions Transfer () and characterizes a state of an exterior resource.

32

Re: Again about business process exceptions (2017)

Hello, sereginseregin, you wrote: S> Speech that function returns only the short technical information to decrypt it all the same it is necessary, therefore there is sense  with difficult exceptions Sense  with exceptions that no them not . There is, of course, a variant that somebody writes empty catch, but it on the order to find out easier, than raw return code.

33

Re: Again about business process exceptions (2017)

S> Give more close to our example with transfer of means. You would do NotEnoughMoneyException or return code? S> in guidelines I do not see anywhere council to do return codes for the given scenario, it is on the contrary written "DO NOT return error codes". S> Transfer of means from the empty account is entirely similar to discovery of a nonexistent file. If at discovery of a nonexistent file it is accepted to throw out an exception why while translating from the empty account it is necessary to arrive differently? X DO NOT use exceptions for the normal flow of control, if possible. Except for system failures and operations with potential race conditions, framework designers should design APIs so users can write code that does not throw exceptions. For example, you can provide a way to check preconditions before calling a member so users can write code that does not throw exceptions. The member used to check preconditions of another member is often referred to as a tester, and the member that actually does the work is called a doer. There are cases when the Tester-Doer Pattern can have an unacceptable performance overhead. In such cases, the so-called Try-Parse Pattern should be considered (see Exceptions and Performance for more information). Variants see. 1) TransferValidationResult ValidateTransfer (int toAccount, decimal amount); long Transfer (int toAccount, decimal amount);//throws an exception at failure 2) bool TryTransfer (int toAccount, decimal amount, out TransferValidationResult transferValidationResult);

34

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> the Classical example,  remittance into the account: S> S> long Transfer (int toAccount, decimal amount); S> S> Function returns transfer number if it is successful. And if it is not successful - there is an exception. Any half measures. It should put in queue and to return number on which it is possible to trace that happens to handling of the given transfer.

35

Re: Again about business process exceptions (2017)

Hello, kov_serg, you wrote: S>> Function returns transfer number if it is successful. And if it is not successful - there is an exception. _> Any half measures. It should put in queue and to return number on which it is possible to trace _> that happens to handling of the given transfer. In what queue?

36

Re: Again about business process exceptions (2017)

Hello, yenik, you wrote: Y> 2) Y> bool TryTransfer (int toAccount, decimal amount, out TransferValidationResult transferValidationResult); the Same return codes, a side view. With the same lacks. Besides FDG: X AVOID using out or ref parameters. Using out or ref parameters requires experience with pointers, understanding how value types and reference types differ, and handling methods with multiple return values. Also, the difference between out and ref parameters is not widely understood. Framework architects designing for a general audience should not expect users to master working with out or ref parameters.

37

Re: Again about business process exceptions (2017)

Hello, yenik, you wrote: Y> Y> X DO NOT use exceptions for the normal flow of control, if possible. So... That's just the point - in a normal case operation transits also you ship the goods. And if to translate means it was not possible, it not a standard situation. Here, even our local MVP, . On guidelines, recommends  Exception: http://rsdn.org/forum/philosophy/6951261.1 the Author: gandjustas Date: 01.11 06:58 It turns out is  2 camps? Y> variants See. Y> 1) Y> TransferValidationResult ValidateTransfer (int toAccount, decimal amount); Y> long Transfer (int toAccount, decimal amount);//throws an exception at failure Before. Check normally transits differently. Before the user translates from the account, he sees residual. If there 0 you simply do not display the button "to translate means" in GUI. If tries to enter the total more you at level of check of the entered data do not allow it to make. On it method Transfer in a normal situation fulfills, after all before. Checks  anyway. Y> 2) Y> bool TryTransfer (int toAccount, decimal amount, out TransferValidationResult transferValidationResult); here, never saw anything similar. Usually operation transits, after all before. Checks become always.

38

Re: Again about business process exceptions (2017)

Hello, kov_serg, you wrote: S>> Function returns transfer number if it is successful. And if it is not successful - there is an exception. _> Any half measures. It should put in queue and to return number on which it is possible to trace _> that happens to handling of the given transfer. No, should not. Function is so optimized that you can cause its 100 thousand times a second. It on 3 orders more than an amount of peak operations in the most loaded days (a maximum there were 100 operations per second). If it is possible to do without queue - it is necessary to do without queue. It is more pleasant to user to make request and at once to receive result. Than to receive the message "thanks, expect queue".

39

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> So... That's just the point - in a normal case operation transits also you ship the goods. And if to translate means it was not possible, it not a standard situation. Ships the goods normally not that at whom is not went right attempt to translate. Particulars it is finite, but characteristic. S> here, even our local MVP, . On guidelines, recommends  Exception: http://rsdn.org/forum/philosophy/6951261.1 the Author: gandjustas Date: 01.11 06:58 That  (Exception, return codes) is substantially perpendicular to that how to organize error handling from the point of view of the user. S> It turns out is  2 camps? It is more. But completely not opposite.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

40

Re: Again about business process exceptions (2017)

Hello, pagid, you wrote: P> Hello, Shmj, you wrote: S>> So... That's just the point - in a normal case operation transits also you ship the goods. And if to translate means it was not possible, it not a standard situation. P> ships the goods normally not that at whom is not went right attempt to translate. Particulars it is finite, but characteristic. Why not that? Wrote off from the internal account, rendered service. S>> here, even our local MVP, . On guidelines, recommends  Exception: http://rsdn.org/forum/philosophy/6951261.1 the Author: gandjustas Date: 01.11 06:58 P> That  (Exception, return codes) is substantially perpendicular to that how to organize error handling from the point of view of the user. We not about display of an error for the user speak, it is other subject. Now return codes vs Exception. S>> It turns out is  2 camps? P> it is more. But completely not opposite. And what except a variant the return code vs Exception is other variants?

41

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> Why not that? The goods are shipped by the one who received money S> Wrote off from the internal account, rendered service. I do not know that such the internal account and at what here service I do not understand, about the goods spoke. S> now return codes vs Exception. S>>> It turns out is  2 camps? P>> it is more. But completely not opposite. S> and what except a variant the return code vs Exception is other variants? Is, variants absolutely without return codes or Exception I will not undertake to advise And here usage for one situations of exceptions, and for other codes quite probably. Whether it is necessary But not strictly two camps generally for other reason - for different languages and at usage of different libraries different variants are possible, nobody will register in one of camps of the abstract reasons.... <<RSDN@Home 1.0.0 alpha 5 rev. 0>>

42

Re: Again about business process exceptions (2017)

Y>> 2) Y>> bool TryTransfer (int toAccount, decimal amount, out TransferValidationResult transferValidationResult); TG> the Same return codes, a side view. With the same lacks. Yes. Sometimes it is necessary to sacrifice principles for the sake of a practicality. TG> TG> X AVOID using out or ref parameters. AVOID! = DO NOT I do not want to be misunderstood: personally exceptions quite are pleasant. Simply they not a unique variant. In FDG I see a certain collision: "do not return the codes of errors, use exceptions" and "do not use an exception for a normal course of performance".

43

Re: Again about business process exceptions (2017)

Y>> Y>> X DO NOT use exceptions for the normal flow of control, if possible. S> So... That's just the point - in a normal case operation transits also you ship the goods. And if to translate means it was not possible, it not a standard situation. S> here, even our local MVP, . On guidelines, recommends  Exception: http://rsdn.org/forum/philosophy/6951261.1 the Author: gandjustas Date: 01.11 06:58 Generally ONLY an exception. It agree, exceptions are pleasant to me. But there are also special cases. S> It turns out is  2 camps? Camps can be even more, and the people can run across from camp in camp depending on a specific situation. Y>> variants See. Y>> 1) Y>> TransferValidationResult ValidateTransfer (int toAccount, decimal amount); Y>> long Transfer (int toAccount, decimal amount);//throws an exception at failure S> If there 0 you simply do not display the button "to translate means" in GUI. From display of the button before its pushing can transit hours. Therefore at operation fulfillment was usefully to recheck it. Y>> 2) Y>> bool TryTransfer (int toAccount, decimal amount, out TransferValidationResult transferValidationResult); S> here, never saw anything similar. Usually operation transits, after all before. Checks become always. If check becomes for an hour before operation it can become irrelevant. Besides, by operation with   there can be surprises, even when all preliminary checks went right. Here it is important to look a specific situation.

44

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> And is more detailed. Here, discovery of a nonexistent file - needs to be thrown out Exception or to return return code? Let's cease speak about "return codes" and 21st century all the same is replaceable it "algebraic type-result". I.e. we will return something a-lja variant <result, error>. Or in the elementary case nullable <T>. S> Why you consider, what transfer of means from the empty account than that differs from discovery of a nonexistent file? I also do not consider. I consider as in that and in that case of an exception are not necessary. Here wrote more low that exceptions cannot be ignored. Humour in that what exactly exceptions are ignored more often than returned values. Only are ignored not in the plan "did not process", and on the contrary, five years ago in the code somewhere above someone wrote catch (...) which deduces in a broad gull. And all. And here already on the code-revju nobody asks a question and why the thrown out exception is not processed in any way, since" It is caught above ". That is caught it caught, only to make something intelligible at this level already it is impossible, since the context is lost. If you try  an intelligible context at you the design of the code will strongly suffer, to be exact connectivity increases in times since overlying layers of logic will be suddenly fastened not only on immediate underlaying, but also on all remaining layers of a pie. Therefore in standard puff design of an exception it is game which is applicable in very restricted scenarios. Well for example in the web application when it is possible to translate any exception at the uppermost level in internal sever error,  and to close completely connection.

45

Re: Again about business process exceptions (2017)

Hello, Masterspline, you wrote: SK>> Prefers to check conditions beforehand. M> system arranged and strongly multi-threaded. Here you checked up that money enough, began transaction, and  already and are not present, and the account is closed/is blocked. It is very improbable. I do not imagine the user at which with its bank account PERMANENTLY there are what that such motions, moreover is imperceptible for it.

46

Re: Again about business process exceptions (2017)

Hello, gandjustas, you wrote: G> To begin with esteem: G> G> https://www.artlebedev.ru/best/ui/humaneness/ G> Well, Lebedev, as usual, is excessively categorical. In some cases "the bureaucratic form of search" much more conveniently and was more general-purpose. Now on a heap of sites such "human" search only hinders.

47

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> That if for the account is not enough money? To throw out exception NotEnoughMoneyException or to envelop result in a wrapper where there will be a return code (type successfully - means 0, and-100500 - means there is no money)? S> As prefers to do the majority? . I for reset of one of two variants: NePoluchilos () Turned out also

48

Re: Again about business process exceptions (2017)

Hello, vmpire, you wrote: V> Well, Lebedev, as usual, is excessively categorical. In some cases "the bureaucratic form of search" much more conveniently and was more general-purpose. V> now on a heap of sites such "human" search only hinders. And an example it is possible? There is a suspicion that there where hinders search, and selection for parameters is necessary not. It too a case when the machine, instead of the person should sweat, but programmers thought in another way.

49

Re: Again about business process exceptions (2017)

Hello, TG, you wrote: TG> Under "preliminary checks" I mean: whether there are enough money for the account, whether the account and so forth is blocked. I.e. all that is "on that side" functions Transfer () and characterizes a state of an exterior resource. I too about them.

50

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> the Question here in what: whether you will use mechanism Exception or return error status code + . Info?  Exception, and the analysis of a probable error + . Info is a separate additional mechanism which is desirable for launching to a procedure call.