Proper way to get error information for functions and class

Question

1.00/5 (1 vote)

See more:

What is the best method for receiving error information from a function/class or application and organizing the information?

I usually return/make public integer error values and have string error values which contain the exception information as public.
All the child function calls keep returning the integer value to the parent functions and this keeps on going until the main function get the error value.

Any advice, articles, books, discussions on how to do this?

Thanks

Posted 15-Apr-13 5:47am

nitrous_007

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-04-15T06:31:00

Solution 1

Forget "error information" and "errors", embrace Structured Exception Handling. Forget collecting and organizing of such information, forget defensive programming in general, forget handling each and every exception case, let go. That all have gone to history.

It's hard to explain the concept in a one quick answer. Structured exception handling is the greatest invention; I value it more than whole OOP. Please see:
http://en.wikipedia.org/wiki/Structured_exception_handling[^],
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680657%28v=vs.85%29.aspx[^],
http://msdn.microsoft.com/en-us/library/ms173160.aspx[^].

I provided a short explanation of the essence of things in my past answer: Does Exception in C# Constructor Cause Caller Assignment to Fail?[^].

Exception handling mechanism is a time machine.

—SA

Posted 15-Apr-13 6:31am

Sergey Alexandrovich Kryukov

Comments

nitrous_007 15-Apr-13 17:39pm

I am not that much of an expert. So here is my attempt at digressing this information-
So are you saying that we should limit the number of try catches and put them in a higher level instead of putting the try catch in a very low level in the program?
What about other errors that are not exceptions?

Sergey Alexandrovich Kryukov 15-Apr-13 17:58pm

Exactly, you caught one of the main points. What is this upper level? This is, first, a very top stack frame the stack of each thread. For a UI thread, the processing is special: in a main loop of the event-oriented UI. All UI library have a special even which you just handle, if you choose the Application option to use this mechanism (in my strong opinion, you always should). Is there something else? Generally, yes. Some exceptions can be handled on top of stack, but not on very top. Where? I call it "competency principle": in the method (stack frame) which is the most competent for handling certain type of exception. Could be more than on intermediate step: some "competency method" handles lower-level exception and "decide" to" 1) handle it completely and block further propagation; 2) handle partially and form an exception of higher level type, to be caught somewhere on top, 3) to re-throw it as is.

Run-time errors which are not exceptions? In modern programming, there are not such things. I can tell you what to do: if you face a legacy sub-system with "errors", create a new class derived from Exception, name it according to the sub-system. If its error can be distinctly classified into some different classes, consider further sub-classing to name them. Encapsulate some information sufficient to get all exception information. And throw those exceptions as early as possible. That its, escape "errors" into exception-handling domain.

—SA

nitrous_007 15-Apr-13 19:03pm

If I create the a class derived from Exception and use it, what is the advantage over the following scenario-
Instead of creating another class, I just store the errorCode and error Strings in some variables and return gracefully from the program.
Is the Exception class just a good way of wrapping up the errorCode and errorString in a nice way? What other advantages would I get from an exception derived class?

Sergey Alexandrovich Kryukov 15-Apr-13 19:14pm

It is like hell compared to heaven. You still did not get the idea. Never ever do what you just suggested. This is not just obvious, this is more than obvious.
I don't understand what to discuss here. Finally, learn exception handling well, to understand this; that's all you need.
—SA

nitrous_007 15-Apr-13 19:23pm

Ok I will keep reading about it.

Sergey Alexandrovich Kryukov 15-Apr-13 20:37pm

Good idea. Will you accept the answer formally (green button)? Nobody is trying to fool you... :-)
—SA