+ 1

Exception of all type not working

Hi All As exception (...) should catch all the exceptions , why it is not working on sololearn compiler? Refer below code : https://code.sololearn.com/cGq53UiWaXTG/?ref=app Is this generic exception is compiler dependent or am I missing something? If it is compiler dependent, isn't it so dangerous as your most convenient safest exception handling does not guarantee due to different compiler implementation?

14th Jan 2021, 6:24 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
9 Antworten
+ 3
The problem is that your p object is a pointer, so the -> would dereference that pointer instead of calling your Test's operator->. In order to call the correct -> you would have to dereference p and then call -> like (*p)->display(); and then it will throw correctly. The problem with that it is easy to make that mistake so that's why you need to abstract things a little bit, hence my example. It kinda functions similar to a unique_ptr or shared_ptr, except that my example didn't manage the object because it would make things a tad more complicated. Personally, I very rarely use throw and just try to avoid those situations in the first place, maybe C++'s library thinks the same, it does allow for better optimizations after all. To be honest, I can't name many functions in the C++ library that throw myself, except maybe the https://en.cppreference.com/w/cpp/string/basic_string/stol family and the at function for classes.
16th Jan 2021, 2:34 PM
Dennis
Dennis - avatar
+ 4
Ketan Lalcheta Accessing deleted memory also doesn't throw exceptions. Like JaScript did in his example you would have to throw yourself. You could use a class to do this like: template<typename T> class H{ public: H( T** t ) : m_T( t ){} T* operator->(){ if( !*m_T ) throw 5; return *m_T; } private: T** m_T; }; Then you simply do Test* t = new Test; H<Test> h = &t; h->display(); // no exception delete t; t = nullptr; h->display(); // exception is thrown
15th Jan 2021, 9:01 AM
Dennis
Dennis - avatar
+ 3
A division by 0 does not throw an exception in C++, so you cannot catch it like this. It does, however, raise a signal, SIGFPE in this case. You can use a signal handler to handle those special cases. https://en.cppreference.com/w/cpp/utility/program/signal Though it's probably overkill in this case when a simple if case works.
14th Jan 2021, 7:06 PM
Dennis
Dennis - avatar
+ 2
The catch(...) expression will be recommended to be used with caution. Better and that works is it to use it in combination with throw statements like here: https://code.sololearn.com/coc7CBbGF4On/?ref=app
14th Jan 2021, 7:08 PM
JaScript
JaScript - avatar
+ 2
I think that throwing all exceptions in a big project is usefull, because you can manage what happend in each situation. Please see again my example, which has been updated with second concrete exception. This one with catch(...) has to be written at the last position of the catch blocks. You can try this code with one of each variable equals 0 as well as with both eqals 0 and see how that works.
16th Jan 2021, 1:41 PM
JaScript
JaScript - avatar
+ 1
Dennis and JaScript thanks a lot... I tried to avoid error of zero division in updated code.... Now trying with pointer exception Created a pointer , called method of class and as expected, it works... Deleted memory of pointer, made it null and again called method but still it calls method without throwing any error... For this scenario, exception should be caught with (...) or not ? Updated this scenario in same attached code.
15th Jan 2021, 3:51 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
+ 1
JaScript correct I got Idea that catch(...) is generic and should be at last after all specific blocks are over.. I thought that we don't have to throw any exceptions and c++ does take care of this...seems this was my perception and we have to throw out by ourselves I have not come across any exceptions thrown by c++ itself rather than we explicitly setting by using throw. Also for the code of Dennis , operator-> is working in other class but not in my same class into my updated code... Many thanks to both of you
16th Jan 2021, 2:10 PM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
So one last question on this... Do we need to throw exception for all the scenarios ? Type casting of illegal type would be compiler error and new memory allocation will be rare to observer due to higher ram size. So when does this (...) Works without throwing exception by code
16th Jan 2021, 11:40 AM
Ketan Lalcheta
Ketan Lalcheta - avatar
0
Also I tried to overload operator -> for same class but not throwing any exceptions yet... I got your point of creating new class but it changes the way I should be calling display method hence tried on same class but no success
16th Jan 2021, 11:48 AM
Ketan Lalcheta
Ketan Lalcheta - avatar