1

Topic: Again about business process exceptions (2017)

How now, already came to a common opinion on this question or not? Earlier there were 2 camps, first of which was pro (especially many representatives in Java-environment), the second against. Reached to ... The Classical example,  remittance into the account: long Transfer (int toAccount, decimal amount); Function returns transfer number if it is successful. And if it is not successful - there is an exception. What if for the account it 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)? How prefers to do the majority?

2

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> Function returns transfer number if it is successful. And if it is not successful - there is an exception. 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)? Except shortage of money can be two more tens reasons for a failure as that "the account is blocked", "transactions through the Internet are forbidden", "the bank of the receiver is inaccessible", "the account of the receiver is blocked".... S> As prefers to do the majority? Prefers to check conditions beforehand.

3

Re: Again about business process exceptions (2017)

Hello, Stanislaw K, you wrote: S>> As prefers to do the majority? SK> prefers to check conditions beforehand. It does not help with the given example for all cases.

4

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> As prefers to do the majority? I prefer to divide errors into "business" and "system". In your example is a business of an error which the user of the program should process.

5

Re: Again about business process exceptions (2017)

Function produces only a stage title on which she stumbled as restrictions in systems (a reserve, account lock, a technical failure of system) and messages on them for reliability register as much as possible a simple language. The stage title does not help the user to make the decision. Account lock can be cancelled in a second after unsuccessful operation, therefore to the user is better specify beforehand in possible errors with provision of as much as possible detail information.

6

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> As now, already came to a common opinion on this question or not? Earlier there were 2 camps, first of which was pro (especially many representatives in Java-environment), the second against. Reached to ... There were no two camps. There were the people who have not studied . S> As prefers to do the majority? The majority prefers to observe : if it is an expected error (for example, the user input) - not to use an exception, and to check explicitly and to return return code (or somehow still to inform on failure). If not expected - to throw an exception and to catch it somewhere in a point of possible recovery. Or not to catch at all generally, depends on application. http://www.informit.com/articles/articl … p;seqNum=6 https://docs.microsoft.com/en-us/dotnet … n-throwing

7

Re: Again about business process exceptions (2017)

Hello, sereginseregin, you wrote: S> Function produces only a stage title on which she stumbled as restrictions in systems (a reserve, account lock, a technical failure of system) and messages on them for reliability register as much as possible a simple language. The stage title does not help the user to make the decision. Account lock can be cancelled in a second after unsuccessful operation, therefore to the user is better specify beforehand in possible errors with provision of as much as possible detail information. And here what for to me as to the user, the nobility what there at you errors are possible. For my part all ? Well also process then. It is to support it is necessary as much as possible information.

8

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> As now, already came to a common opinion on this question or not? Earlier there were 2 camps, first of which was pro (especially many representatives in Java-environment), the second against. Reached to ... 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. 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? Remittance is long enough operation to return better therefore result in the form of object representing transfer. In one cases we throw an exception (there is no money for the account, the account is blocked), in others the client receives the information on an error checking the status of object representing remittance.

9

Re: Again about business process exceptions (2017)

S>> As prefers to do the majority? V> the majority prefers to observe : if it is an expected error (for example, the user input) - not to use an exception, and to check explicitly and to return return code (or somehow still to inform on failure). V> If not expected - to throw an exception and to catch it somewhere in a point of possible recovery. Or not to catch at all generally, depends on application. The answer is too spheric in vacuum. Expected/not Expected is not always a binary state. What if expected, but very rare?

10

Re: Again about business process exceptions (2017)

Hello, yenik, you wrote: S>>> As prefers to do the majority? V>> the majority prefers to observe : if it is an expected error (for example, the user input) - not to use an exception, and to check explicitly and to return return code (or somehow still to inform on failure). V>> If not expected - to throw an exception and to catch it somewhere in a point of possible recovery. Or not to catch at all generally, depends on application. Y> the answer is too spheric in vacuum. Expected/not Expected is not always a binary state. What if expected, but very rare? And here for answers to such questions also there is a system architect or the chief programmer who should decide that as for the given specific project. Because without knowledge of specificity of the project it always will be the spherical answer in vacuum. Somewhere and on errors of the user it is possible to throw exceptions (for example if high-grade check was in the previous layer of application). And somewhere and the missing file of a configuration or division into a zero is equated to an expected error (if, for example, it  system which  to work at any cost, even with risk of misoperation).

11

Re: Again about business process exceptions (2017)

Y>> the Answer is too spheric in vacuum. Expected/not Expected is not always a binary state. What if expected, but very rare? V> and here for answers to such questions also there is a system architect or the chief programmer who should decide that as for the given specific project. It is true. In effect, the question in the start message is spheric. Here followed begin with clearing up of singularities of implementable system.

12

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> As prefers to do the majority? In overwhelming majority of cases usage of exceptions is a design error.

13

Re: Again about business process exceptions (2017)

Hello, GarryIV, you wrote: GIV> And here what for to me as to the user, the nobility what there at you errors are possible. For my part all ? Well also process then. It is to support it is necessary as much as possible information. I.e. the account was blocked by police officers, or money reserved other commission is a problem of support desk? Speech that function returns only the short technical information to decrypt it all the same it is necessary, therefore there is no sense  with difficult exceptions

14

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> As now, already came to a common opinion on this question or not? Earlier there were 2 camps, first of which was pro (especially many representatives in Java-environment), the second against. Reached to ... Now the judgement tends "the codes of errors", but is active  both approaches. Or hierarchy of exceptions, or sealed hierarchy objects of errors when the compiler can check up that all cases are processed. All depends on error handling strategy in the program. Whether error handling depends on error type? In the web application it is often enough to tell "500" and to write down  in a broad gull, and somewhere all possible errors it is necessary to process carefully. Often  the intermediate variant then very important correctly to classify errors. Played back/casual. User/system. Known/unknown. Where errors are processed? In a place of origin or on the top? Whether the error should to contain the structured information about a context?, Etc.

15

Re: Again about business process exceptions (2017)

Hello, Stanislaw K, you wrote: SK> Prefers to check conditions beforehand. What means beforehand? You checked up,  were. While caused - money already is not present.

16

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? To generate TransferException in which field "reason" is equal-100500 that means "there is no money"

17

Re: Again about business process exceptions (2017)

Hello, Real 3L0, you wrote: S>> As prefers to do the majority? R3> I prefer to divide errors into "business" and "system". In your example is a business of an error which the user of the program should process. And how function informs the user that an error? Returns error status code or  an exception?

18

Re: Again about business process exceptions (2017)

Hello, sereginseregin, you wrote: S> Function produces only a stage title on which she stumbled as restrictions in systems (a reserve, account lock, a technical failure of system) and messages on them for reliability register as much as possible a simple language. The stage title does not help the user to make the decision. Account lock can be cancelled in a second after unsuccessful operation, therefore to the user is better specify beforehand in possible errors with provision of as much as possible detail information. A question here in what: whether you will use mechanism Exception or return error status code + . Info?

19

Re: Again about business process exceptions (2017)

Hello, vmpire, you wrote: S>> As prefers to do the majority? V> the majority prefers to observe : if it is an expected error (for example, the user input) - not to use an exception, and to check explicitly and to return return code (or somehow still to inform on failure). The user input and an expected exception (as in Java) is a little different. For example at discovery of file FileNotFoundException - will be expected, but you not begin to use return code in this case? V> if not expected - to throw an exception and to catch it somewhere in a point of possible recovery. Or not to catch at all generally, depends on application. V> http://www.informit.com/articles/articl … p;seqNum=6 V> https://docs.microsoft.com/en-us/dotnet … n-throwing give more close to our example with transfer of means. You would do NotEnoughMoneyException or return code? 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". 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?

20

Re: Again about business process exceptions (2017)

Hello, Qulac, you wrote: Q> Remittance is long enough operation to return better therefore result in the form of object representing transfer. In one cases we throw an exception (there is no money for the account, the account is blocked), in others the client receives the information on an error checking the status of object representing remittance. I.e. you for Exception? Well here, and above speak that any two  are not present also all consider equally...

21

Re: Again about business process exceptions (2017)

Hello, antropolog, you wrote: S>> As prefers to do the majority? A> in overwhelming majority of cases usage of exceptions is a design error. And is more detailed. Here, discovery of a nonexistent file - needs to be thrown out Exception or to return return code? Why you consider, what transfer of means from the empty account than that differs from discovery of a nonexistent file?

22

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. In what advantage of the codes of errors?

23

Re: Again about business process exceptions (2017)

SK> Prefers to check conditions beforehand. 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.

24

Re: Again about business process exceptions (2017)

Y> Expected/not Expected is not always a binary state. What if expected, but very rare? As I understand, it depends on a method which you are going to react to an error. If right after reset from function - then return code if in an indefinite place to make rollback - then an exception. Thus there is the transitive "gray" zone when for the same method error status code handling is possible in one project, and in other it is possible to bang application easy. For any methods both variants (with error status code and an exception) should be provided.

25

Re: Again about business process exceptions (2017)

Hello, Shmj, you wrote: S> As now, already came to a common opinion on this question or not? Earlier there were 2 camps, first of which was pro (especially many representatives in Java-environment), the second against. Reached to ... S> Function returns transfer number if it is successful. And if it is not successful - there is an exception. 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)? Generally ONLY an exception. Without variants. The codes of errors are too easy for ignoring. For example after remittance to the client the goods go. Forgot to check up error status code - , the customer lost money. There are some special cases when it is possible to depart from this rule. For example if remittance - the end result necessary to the user. That is the result will be directly displayed on the screen and will not be processed in any way more. The second example - "pattern" TryOperation. When the positive and negative result of function are equiprobable and in case of the negative result the program will do something else, instead of simply interrupts operation. But even Try-functions will throw exceptions in certain cases.