No, it is possible to catch an exception anywhere in the call stack. As the stack is unwound, the exception is passed up the stack until it is handled.

Yes it has difference

The debugger provides a much more powerful mechanism for stepping through your code and watching values change without having to clutter your code with thousands of debugging statements. In addition, there is a significant risk each time you add or remove lines from your code. If you have just removed problems by debugging, and you accidentally delete a real code line when deleting your use of cout, you haven't helped the situation.

A regular function (nontemplate) takes parameters on which it can take action. A template function enables you to parameterize the type of a particular parameter to the function. That is, you can pass an Arrayof Typeto a function and then have the Typedetermined by the definition of the variable that is an instance of the class for a specific type.

• It permits code reusability
• It encourages the reuse of proven and debugged highquality software, thus reducing problem after a system becomes functional
• Reusability saves time in program development

Templates are type-safe and built in to the language, so they are checked by the compiler-at least when you instantiate the class to create a particular variable.

Technically, yes. However, this is a bad practice as destructors are also called when the stack is unwound due to an exception. So, a destructor invoked due to an exception throwing an exception itself can clearly result in quite an ugly situation for the state of an already unstable application trying to make a clean exit.

Yes it has difference

It seems that your application does all the activity within one thread. So, if the image processing itself (contrast correction) is processor intensive, the UI is unresponsive. You ought to split these two activities into two threads so that the OS switches the two threads, giving processor time to both the UI and the worker that does the correction.

Your threads are possibly poorly synchronized. You are writing to and reading from an object at the same time, resulting in inconsistent or garbled data recovery. Insert a binary semaphore and ensure that the table cannot be accessed when it is being modified.

A class just like any other, but created expressly as a base class for some other exception classes such as bad_alloc.

That's a bad idea for it's also possible that the exception was thrown in the first place because of a lack of memory.