Tag Info

New answers tagged

3

To draw the line between exceptions and return values, I would try to stick to the following: - Anytime an instruction breaks the expected flow of execution, you expect an error to be thrown. - If the expected function of procedure may have different outcomes, you will want to work with return values. In the examples that you are stating, it seems very ...


1

What you have here is the most generic form of Exception, which is only of any real use in a "global" Exception Handler - you know the sort of thing: show a "message" to the user, [hopefully] record the Exception into a file for [your] later diagnostic use, then allow the program to gracefully collapse in a heap, losing everything that the user has done for ...


0

Yes: they should state what is wrong & the type of error. Lets look at a couple of examples for exceptions. Under C++, if you run out of memory, the new command will throw an exception. This is IMHO a good use. Its something which does happen & you will need to catch & deal with it. Another exception you might have is an exception thrown if ...


32

Yes, it's fine (actually, it's good) to make the default constructor unusable if there's no sensible way to initialize the object without any arguments. But don't "disable" it by throwing an exception. Make it private instead. Ideally your interface won't contain any methods or constructors people "aren't supposed to" call.


1

You must distinguish between exceptions for expected error conditions and exceptions that represent bugs in your program. Let's suppose you've forbidden null in your codebase, or at least within a particular class. If you ever find a null value in one of your private variables, that unambiguously indicates a bug. It's fine to use some generic "something ...


5

Short answer: NO Long answer: You are getting the concept of exceptions wrong. Exceptions do not tell the user there's something wrong. It's the calling program that should catch the exception and tell (or not tell) the user something is wrong or recover from it graciously. If an "exception" has code inside to "fix" something, then it's not an ...


7

The main reasons for using namespaces are the avoidance of name collisions, and to add logical grouping. But since exception class names typically have the form "XYZException" (and other classes have not), those two requirements are already fulfilled by that naming convention. Thus adding an additional sub-namespace is just unneccessary in a context where ...



Top 50 recent answers are included