Exception handling in a large project

Hello all,

I have a question here: In a large C++ project, how would you do exception handling?

In my last project, which was in PHP, I designed the exception handling structure. I simply used exception classes. There were several exception classes like "ExternalException", "CallingFunctionException" and a few others. Based on this, a few other exception classes were based ("InvalidParameterException" on CallingFunction, "InvalidPermissionException" on External, etc). I think it was quite useful - since it could automatically find out which programmer should likely be responsible for fixing the problem quite nicely - but in general, this would be quite an overkill for C++ projects.

I could simply have one layer of exception classes, for every possible exception ("FileNotFoundException", "InvalidPermissionException", etc). On this method, a catch can easily be done for only several types that can be handled by the function.

For multiple exceptions, however, you have to override the constructor manually for every base class. So every exception takes a few lines (With eg. InvalidPermissionException(const char *what) : ExceptionBase(what) {}).
Some time ago I simply used a class that would be called like:

Code:

---

Exception<InvalidPermissionException>::doThrow("Message here");

---

This made it possible to declare an extra exception really easy (class SomeException : public ExceptionBase {}).
Another project, I simply made a "#define". I know they're considered evil in general, but again, I could simply declare an exception with a single macro, it would automatically create a class and add the constructor needed.

That's about the summary of my ideas. What do you guys think is the best method? Is there a better method than the ones I mentioned and if not, which method do you think is best?


Thanks,
EVOEx

I don't think a macro would be that evil here.

But how does the doThrow version work exactly?

Thanks for your reply.

The Exception class had a static member called doThrow. This would create the class passed in brackets using the template argument. These classes could only be instantiated using this function. Then the function would set the exception message passed to the function (not through a constructor, as this avoided using a constructor for all classes).
The exception base class had this exception generator class as a friend. So it could directly write to the exception pointer (or I used an interface function that existed in the exception base, I don't remember).

So, do you guys have a better method? Or would you guys use exceptions at all? (Ah, I will use it unless speed is critical in the application, but I would just like to know)


Thanks

Quote:

---

Originally Posted by EVOEx

For multiple exceptions, however, you have to override the constructor manually for every base class.

---

That would not really be overriding the constructor, but simply defining a constructor for the new class. Personally, I do not bother too much and simply manually define the exception classes with a constructor, but I suppose a macro would help if you really wanted to reduce the amount of typing.

Incidentally, I typically derive my exception classes from either std::logic_error or std::runtime_error, and hence keep the respective constructor's signature such that it takes a std::string instead of a const char*.

Thanks for your answer (and happy birthday :P, I noticed on the front page).

What you're saying sounds good. I don't bother creating a constructor for every class either per se, but my experience is that it becomes an unreadable mess. I guess what you're saying is best for me, using those two exceptions as base classes. And I guess I will use macro's here, since I consider this a lot more readable:

Code:

---

DECLARE_EXCEPTION(InvalidArgumentException, std::logic_error);

---

A lot better than:

Code:

---

class InvalidArgumentException : public std::logic_error { InvalidArgumentException(const std::string &what) : std::logic_error(what) {} };

---

Thanks,
EVOEx

Quote:

---

In my last [...] quite an overkill for C++ projects.

---

I use this approach in all of my code--in languages that support exceptions. Having several dozen exception classes that defines the kind of exception without further inspection is never overkill. This approach provides too many advantages to ignore.

Quote:

---

I could simply have one [...] handled by the function.

---

I don't like the idea of a single layer. If I need to deal with 'FileNotFoundException' and 'InvalidPermissionException' at a particular level I may have to duplicate code, separate the exception handling logic into an otherwise useless function, or "translate" the exception.

Quote:

---

Exception<InvalidPermissionException>::doThrow("Me ssage here");

---

I use something similar. You throw and catch 'exception<TAG>::type'. The 'TAG' can be any type you like. The meta-programming handles all the work you're afraid of duplicating.

Quote:

---

Another project, I simply made a "#define".

---

Using a macro for this is fine. (I just wouldn't suggest that you use a macro.)

Happy birthday, LL.

Soma

Quote:

---

Originally Posted by EVOEx

I guess what you're saying is best for me, using those two exceptions as base classes.

---

Yes, whether directly or indirectly. I find that it also makes sense to just use one of their immediate derived classes at times, like std::invalid_argument.

Quote:

---

Originally Posted by EVOEx

And I guess I will use macro's here, since I consider this a lot more readable:

---

I might name the macro DEFINE_EXCEPTION instead, in view that this is also a declaration of the InvalidArgumentException class:

Code:

---

class InvalidArgumentException;

---

Oh, and thanks for the birthday wishes :)

So the best solution is to use multiple layers, probably... You may be right there.

And I guess I'll use the macro to define them - and you're right btw, your name is better ;).


Thanks a lot, all of you ;).