1

Topic: Dial-up of exceptions of a method

Greetings to all. At me such question - in the project becomes to a fig of exceptional situations. For example, there is a difficult method which already throws a heap of different exceptions. Certainly  it is possible to break into some methods and to simplify, but that is not the question. How to organize all these exceptions of various methods in the project? Was more specific: whether it is necessary to use exceptions which are not inherited from std:: exception? Whether it is necessary to inherit all exceptions from any one class, for example, from std:: runtime_error - that the hierarchy of exceptions had the unique root? Whether it is necessary to group somehow exceptions in groups (i.e. for each method the group of exceptions)? Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer?

2

Re: Dial-up of exceptions of a method

Hello, developer, you wrote: D> Greetings to all. D> at me such question - in the project becomes to a fig of exceptional situations. For example, there is a difficult method which already throws a heap of different exceptions. Certainly  it is possible to break into some methods and to simplify, but that is not the question. How to organize all these exceptions of various methods in the project? D> it is is more specific: whether D> it is necessary to use exceptions which are not inherited from std:: exception? Whether D> it is necessary to inherit all exceptions from any one class, for example, from std:: runtime_error - that the hierarchy of exceptions had the unique root? Whether D> it is necessary to group somehow exceptions in groups (i.e. for each method the group of exceptions)? D> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? void panic (); void smart_fn () {try {timid_fn ();} catch (...) {panic ();}} void panic () {try {throw;} catch (A &a) {... throw "A";} catch (B &b) {... throw "B";} catch (a C &c) {if (! ignore_c) throw;} catch (std:: exception &e) {...}...//100500 more different variants catch (...) {real_panic ();}}

3

Re: Dial-up of exceptions of a method

Hello, developer, you wrote: D> Greetings to all. D> at me such question - in the project becomes to a fig of exceptional situations. For example, there is a difficult method which already throws a heap of different exceptions. Certainly  it is possible to break into some methods and to simplify, but that is not the question. How to organize all these exceptions of various methods in the project? D> it is is more specific: whether D> it is necessary to use exceptions which are not inherited from std:: exception? I do not see special sense. Easier all the same to inherit from the standard. Whether D> it is necessary to inherit all exceptions from any one class, for example, from std:: runtime_error - that the hierarchy of exceptions had the unique root? Yes, it is quite natural - to have one base class of exceptions. Here is more detailed: whether https://isocpp.org/wiki/faq/exceptions http://en.cppreference.com/w/cpp/error/exception https://www.tutorialspoint.com/cplusplu … ndling.htm http://www.cplusplus.com/doc/tutorial/exceptions D> it is necessary to group somehow exceptions in groups (i.e. for each method the group of exceptions)? Whether it is necessary to complicate? Do as it is possible is easier: https://en.wikipedia.org/wiki/KISS_principle D> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? In style of a C ++ all the same - to throw an exception; In style of a C - to return  Priimushchestvo of an exception - it is less than probability that the problem remains not noted. P.S. Here still the helpful information: https://stackoverflow.com/questions/122 … e-messages https://stackoverflow.com/questions/307 … d-print-it Application std:: exception_ptr: http://en.cppreference.com/w/cpp/error/exception_ptr https://stackoverflow.com/questions/142 … eption-ptr https://msdn.microsoft.com/en-us/library/dd293602.aspx

4

Re: Dial-up of exceptions of a method

Hello, AlexGin, you wrote: AG> Yes here is more detailed: AG> https://www.tutorialspoint.com/cplusplu … ndling.htm To division examples not so http://tpcg.io/5Dl7Bh D>> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? AG> in style of a C ++ all the same - to throw an exception; In style of a C - to return  In a C return code all hurt and! =0 error status code. rc=func (); if (rc) log_error (rc);

5

Re: Dial-up of exceptions of a method

Hello, kov_serg, you wrote: _> Hello, AlexGin, you wrote: AG>> Yes here is more detailed: AG>> https://www.tutorialspoint.com/cplusplu … ndling.htm _> To division examples not so http://tpcg.io/5Dl7Bh D>>> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? AG>> in style of a C ++ all the same - to throw an exception; In style of a C - to return  _> In a C return code all hurt and! =0 error status code. _> _> rc=func (); if (rc) log_error (rc); _> yes, but it not everywhere. So, WinAPI it is constructed so that for error status code obtaining - it is necessary to call GetLastError (): https://msdn.microsoft.com/en-us/librar … p/ms679360 (v=vs.85).aspx

6

Re: Dial-up of exceptions of a method

Hello, AlexGin, you wrote: D>>>> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? AG>>> in style of a C ++ all the same - to throw an exception; In style of a C - to return  _>> In a C return code all hurt and! =0 error status code. _>> _>> rc=func (); if (rc) log_error (rc); _>> AG> yes, but it not everywhere. AG> So, WinAPI it is constructed so that for error status code obtaining - it is necessary to call GetLastError (): AG> https://msdn.microsoft.com/en-us/librar … p/ms679360 (v=vs.85).aspx Aha still is WSAGetLastError and it is simple BOOL, both HRESULT, and HANDLE... In winapi always aspired to take and make all differently and their uniformity worried in the last queue. The only thing that at them was constant it love to do functions with a large quantity of useless parameters and then to add  functions (but it is better) with even considerable quantity of parameters.

7

Re: Dial-up of exceptions of a method

Hello, developer, you wrote: D> At me such question - in the project becomes to a fig of exceptional situations. For example, there is a difficult method which already throws a heap of different exceptions. Certainly  it is possible to break into some methods and to simplify, but that is not the question. How to organize all these exceptions of various methods in the project? I advise  a macro with a succession catch'. At me  is  (for Windows also the system error report is pulled out), by it also the stack untwists. But I only two types of exceptions catching: std:: runtime_error and (...). The macro transforms all exceptions in std:: runtime_error and  further. In root function catching already normal catch (std::runtime_error&) As a result the code looks as try {...} RETHROW At will it is possible FINALLY to fasten More low a fragment of the description of macroes, the auxiliary class CError storing a stack in TLS, and as truntime_error/tstring, successors std:: runtime_error/std:: basic_string for support UNICODE is involved. STDERROR for throwing of the exceptions, SYSERROR for message addition with the system description of an error:... #ifdef linux #define __ FUNCTION __ __ func __ #endif #define STACK_TRACE (CError:: PopStackTrace () + _T ("\n") + _T (__ FUNCTION __)) #define RETHROW \catch (truntime_error &e) {\if (CError:: GetStackTrace ().empty ()) CError:: GetStackTrace () = e.what (); \CError:: GetStackTrace () + = tstring (_T ("\n")) + _T (__ FUNCTION __); \throw;} \catch (...) {\if (CError:: GetStackTrace ().empty ()) CError:: GetStackTrace () = _T ("Unhandled exception"); \CError:: GetStackTrace () + = tstring (_T ("\n")) + _T (__ FUNCTION __); \throw;} ... #define STDERROR (message) CError:: ThrowStdError (_T (__ FILE __), __ LINE __, _T (message)) #define SYSERROR (message) CError:: ThrowSysError (_T (__ FILE __), __ LINE __, _T (message))...

8

Re: Dial-up of exceptions of a method

Hello, AlexGin, you wrote: D>> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? AG> in style of a C ++ all the same - to throw an exception; In style of a C - to return  AG> Priimushchestvo of an exception - it is less than probability that the problem remains not noted. Well here is dynamic_cast, with double behavior: in one case null, in other - an exception

9

Re: Dial-up of exceptions of a method

Hello, Ops, you wrote: Ops> Well here is dynamic_cast, with double behavior: in one case null, in other - the exception dynamic_cast - with pointer conversion returns null (pointers are in ANSI-C), dynamic_cast - with link conversion throws an exception (links appeared in a C ++) - in general logically.

10

Re: Dial-up of exceptions of a method

Hello, AlexGin, you wrote: AG> dynamic_cast - with pointer conversion returns null (pointers are in ANSI-C), Only here anything similar dynamic_cast in a C is not present, so it would be possible and to throw. So it is made most likely that it was possible to resolve it bar none. But it contradicts "In style of a C ++ all the same - to throw an exception" AG> dynamic_cast - with link conversion throws an exception (links appeared in a C ++) - in general logically. It is finite, with links I of other variants at all do not see.

11

Re: Dial-up of exceptions of a method

Hello, Ops, you wrote: Ops> Hello, AlexGin, you wrote: AG>> dynamic_cast - with pointer conversion returns null (pointers are in ANSI-C), Ops> Only here anything similar dynamic_cast in a C is not present, so it would be possible and to throw. So it is made most likely that it was possible to resolve it bar none. But it contradicts "In style of a C ++ all the same - to throw an exception". Yes, dynamic_cast in a C, naturally, no. But as it returns pointer null-pointer here it is as though logical. AG>> dynamic_cast - with link conversion throws an exception (links appeared in a C ++) - in general logically. Ops> it is finite, with links I of other variants at all do not see. For today, IMHO the most demanded variant at all dynamic_cast, and std:: dynamic_pointer_cast <...> (...) - Its call in case of failure returns nullptr. http://en.cppreference.com/w/cpp/memory … inter_cast http://www.cplusplus.com/reference/memo … inter_cast

12

Re: Dial-up of exceptions of a method

Hello, AlexGin, you wrote: AG> Yes, dynamic_cast in a C, naturally, no. But as it returns pointer null-pointer here it is as though logical. Why? It some kind of error status code. Perhaps in a C ++ different lines of thought nevertheless are used, and unambiguously to state, what in its style to throw - incorrectly?

13

Re: Dial-up of exceptions of a method

Hello, Ops, you wrote: Ops> Hello, AlexGin, you wrote: AG>> Yes, dynamic_cast in a C, naturally, no. But as it returns pointer null-pointer here it is as though logical. Ops> why? It some kind of error status code. Perhaps in a C ++ different lines of thought nevertheless are used, and unambiguously to state, what in its style to throw - incorrectly? Yes, on a C ++ different lines of thought are used. But  the approach with ejection exception prevails nevertheless. If to look aside STL, all the same exceptions - the main method of generation/processing of errors. Nevertheless - sometimes error status code application really adhere: https://news.ycombinator.com/item?id=4563914

14

Re: Dial-up of exceptions of a method

Hello, AlexGin, you wrote: AG> Yes, on a C ++ different lines of thought are used. But  the approach with ejection exception prevails nevertheless. You  in this case, as well as in many other cases concerning a C ++, appears rather far from the validity. By results of a recent C ++ Developers Survey only ~48 % With ++ developers have possibility freely to use exceptions, and in 20 % of cases of an exception generally are under an absolute prohibition. Also the codes of errors and special classes, like folly:: Expected or outcome:: result are much more often used.

15

Re: Dial-up of exceptions of a method

Hello, developer, you wrote: whether D> it is necessary to use exceptions which are not inherited from std:: exception? If you do library, most likely, without inheritance from std:: exception you deliver more efforts to users of the library. If the code does not fall outside the limits your command it is possible to do everything, everything. But to you it will be easier, if on catch (const std:: exception you can catch and own exceptions. Whether D> it is necessary to inherit all exceptions from any one class, for example, from std:: runtime_error - that the hierarchy of exceptions had the unique root? Yes. For example, do my_exception the successor std:: exception (or std:: runtime_error if want), and already from my_exception inherit remaining exception classes. Whether D> it is necessary to group somehow exceptions in groups (i.e. for each method the group of exceptions)? Depends, at least, on two things: 1. Volume of your code base and its sharing on more or less independent units. If at you small code base and strongly pronounced units are not present, it is possible to manage only one class of an exception. If the code base big (we tell from 50-100KLOC and more) and is the units which are responsible for different functionality (we tell, net unit for operation with a network, db for operation from a DBMS, crypto for cryptography etc.) for each unit it is possible to make the base class of an exception. Then it will be easier to filter the problems concerning the specific unit. Something like: try {auto raw_data = net:: recv_msg (channel); auto data = crypto:: decrypt_msg (raw_data);...} catch (const crypto:: exception and x) {...//In special way we process decoding errors.} Thus you can have here such hierarchy of exceptions: std:: exception ` - my_exception ` - net:: exception | `-... ` - crypto:: exception `-...... 2. If you need to group any data sets describing an error in the exceptions. For example, in any cases you need to transfer file name and the system mistake code in an exception. In any cases user name and the reason of impossibility of its authentification. In any cases an inadmissible index and an actual allowed range of indexes. Here if at you such cases are, then you can create separate branches of hierarchy of exceptions: std:: exception ` - my_exception ` - file_error (name, error_code) | ` - open_file_error | ` - read_file_error | ` - unlink_error |... ` - user_auth_error (user_name, reason) ` - unknown_user_error ` - no_permission_error ` - disabled_user_error `-... D> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? In such cases are guided by three major factors: 1. The exception needs to be thrown in exceptional situations. I.e. if the probability to receive unsuccessful result is high, the unsuccessful result is quite to itself a normal outcome, instead of an unusual case. And the return code here will be more pertinent, than an exception. If the probability of failure is low, it is better to throw an exception. 2. Gravity of consequences if the exception is not thrown, and the user forgets to check up return code. For example, you do a method memory_arena:: preallocate which returns you the pointer on the reserved segment. If the user forgets to check up the returned pointer and to address on it the program fails in case of null pointer reset. Whereas at burst of an exception of it does not happen. However, in the modern world for such cases can be more favourable to use specialized classes like folly:: Expected or outcome:: result. 3. The price of burst of an exception. If at you exceptions can rush often even there where exceptions are implemented effectively, all of you equally face with noticeable  productivity. Hardly it will suit you and in such cases it is better to you to prefer returned values to exceptions.

16

Re: Dial-up of exceptions of a method

Hello, so5team, you wrote:... https://isocpp.org/files/papers/CppDevS … ummary.pdf I would treat the given statistics so: In 20 % to use exceptions it is impossible. That is, in remaining 80 %, they can use all the same. For return codes of errors - requirements not such strict: there it is impossible to use in 11 % (in remaining 89 % it is possible).

17

Re: Dial-up of exceptions of a method

Hello, so5team, you wrote:... All is quite logical and correct (respected so5team, I am not engaged in faultfinding). But, nevertheless, you strange enough treat concept "Gravity of consequences": S> 2. Gravity of consequences if the exception is not thrown, and the user forgets to check up return code. For example, you do a method memory_arena:: preallocate which returns you the pointer on the reserved segment. If the user forgets to check up the returned pointer and to address on it the program fails in case of null pointer reset. Whereas at burst of an exception of it does not happen. Means, if I, working as the Customer, performing important operation on your application, received  or hangup, it more a serious consequence than if I silently and easy received incorrect result of calculations - which (probably through an oversight as to mine, and other persons), transferred further - for example for designers of the atomic power station or the cosmodrome...

18

Re: Dial-up of exceptions of a method

Hello, so5team, you wrote: S> you  in this case, as well as in many other cases concerning a C ++, appears rather far from the validity. S> by results of a recent C ++ Developers Survey only ~48 % With ++ developers have possibility freely to use exceptions, and in 20 % of cases of an exception generally are under an absolute prohibition. Also the codes of errors and special classes, like folly:: Expected or outcome:: result are much more often used. Situations when exceptions  are forbidden, not so it is a lot of, your statistics speaks about  at employers, rather than about language more likely. One Google with the code style that costs, and some produce it for "good practice".

19

Re: Dial-up of exceptions of a method

Hello, developer, you wrote: D> Sometimes happens equally pertinently either to return false or to throw an exception - what to prefer? The general rule: exceptions for exceptional situations. And that saw I of the enthusiasts, which exceptions used as return codes: wanted - the size returned, or a point, and wanted HRESULT. Also it is all from one function.

20

Re: Dial-up of exceptions of a method

Hello, AlexGin, you wrote: AG> Means, if I, working as the Customer, performing important operation on your application, received  or hangup, it more a serious consequence than if I silently and easy received incorrect result of calculations - which (probably through an oversight as to mine, and other persons), transferred further - for example for designers of the atomic power station or the cosmodrome... Forgive, but the sensation is once again added that you have not enough brains of experience in software development that you understood about what there is a speech. Or you try  instead of taking the trouble to understand that has been told.

21

Re: Dial-up of exceptions of a method

Hello, so5team, you wrote: Thanks! Very much a good advice! Wanted to ask still - as means of language of a C ++ to express the interface of a class which throws exceptions? namespace net {class Reciever {Result recv_msg (Channel channel)//this method throws exception RecieveException};} How to express what the method throws exceptions C means ++? Or to describe it in the documentation to a class? And if there is no documentation? And the library (without source codes) is given to the customer. And even if with source codes, the customer that-whether will study source codes learn what exceptions can to be thrown out?

22

Re: Dial-up of exceptions of a method

Hello, developer, you wrote: D> Wanted to ask still - as means of language of a C ++ to express the interface of a class which throws exceptions? In the modern C ++ you can promise only not to throw exceptions generally - mark a method/function as noexcept. If noexcept is not present, means exceptions can take off. What? You cannot know it. Therefore, by the way, it is better to inherit the exceptions from std:: exception. PS. noexcept does not mean that the compiler gives to you on hands if in noexcept a method/function you try to throw an exception (or cause other methods/functions which throw exceptions). You are able to do it, but in case of exception origin your program will be interrupted. Therefore the one who causes noexcept methods/functions, can about exceptions of these methods/functions does not worry.

23

Re: Dial-up of exceptions of a method

Hello, developer, you wrote: D> Thanks! Very much a good advice! Wanted to ask still - as means of language of a C ++ to express the interface of a class which throws exceptions? namespace net {class Reciever {Result recv_msg (Channel channel) throw (RecieveException);//or throw (...) for an indefinite circle of exceptions} But such syntax since a C ++ 17 promised to make depricated. And the Microsoft on it a bolt laid down from the very beginning. I.e. syntax resolves, but fairly notifies that it ignores it.