![]() |
|
![]() |
|
|
Thread Tools | Display Modes |
|
|
#1 |
|
Newbie
Join Date: Mar 2007
Posts: 24
Rep Power: 0
![]() |
exception handling
Hello..
I have some questions about exception handling in c++.. I know its the best to throw object when exception occurs and I wonder what is the best way to do this. I was thinking about deriving class from std::exception.. Something like: class myexception : public std::exception {
public:
//...//
};I wonder: Would it be smart to do it this way? How do you guys do it? Would it be smart to have members for storing last_error and other information? Maybe it would be good to throw it this way (with description): throw myexception("function() - this is the problem");Next question: Show I have more classes to handle different sorts of exceptions? For instance exception that would make program exit, etc.. Thanks a lot for answers |
|
|
|
|
|
#2 |
|
Resident Grouch
![]() ![]() ![]() ![]() ![]() ![]() Join Date: Jun 2005
Posts: 6,453
Rep Power: 10
![]() |
You might want to review the article referenced in my sig (Grumpy on C++ exceptions).
__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers |
|
|
|
|
|
#3 |
|
Programming Guru
![]() Join Date: Jun 2005
Location: Adelaide, South Australia
Posts: 1,254
Rep Power: 5
![]() |
That little article referred to by Dawei covers broader questions than l2u's.
std::exception supplies a virtual function of the form; char *what() const; Generally, I'm an advocate of having a number of small and simple exception classes (one for each class of error) which allows it to be caught and handled. At most, I may pass some simple data back (eg some error codes) as data members. In practice, I rarely create classes derived from std::exception. It is never a good idea for an exception class (whether derived from std::exception or not) to rely on dynamic memory allocation (which means an exception class can not have a member which is an std::string or any other standard container). The reason is that a failure during creation of the exception (or copying, as is required during stack unwinding) can cause confusion (eg caller receiving a different exception from that intended). I never write an exception to "make a program exit". If I want a program to exit, I call exit() or abort(). Exceptions are an error reporting mechanism, not a program termination mechanism. If I throw an exception, it means I expect that a caller has some (albeit, often small in practice) chance of recovering from the error and the error is severe enough that it shouldn't be ignored. If the caller neglects to handle an exception, then the caller (or more accurately the programmer who wrote the caller) accepts that a consequence is program termination. |
|
|
|
![]() |
| Bookmarks |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Exception Handling with Threads | Harakim | Software Design and Algorithms | 13 | Aug 8th, 2006 7:00 AM |
| Could some please explain classes to me... | TCStyle | C++ | 10 | Feb 20th, 2006 4:51 PM |
| AhhH!!! I can't find anything on this exception... | stakeknife | ASP | 2 | Sep 26th, 2005 8:48 AM |
| Ranting | uman | C++ | 27 | Jun 17th, 2005 1:02 PM |
| exception handling | chrome_knob | Java | 2 | May 19th, 2005 6:45 PM |