Custom Class Exception/Error Handling

Question

0.00/5 (No votes)

See more:

Hi all,

Suppose in my custom/library class I have a method which accepts an integer parameter. The value of the input parameter should be between 0 and 10. If it is not then that constitutes an error. Obviously I can programatically check the integer value and so this is not strictly speaking an exception situation and so it doesn't seem approrpiate to throw an exception when the value is invalid. My then question is how should this error state be communicated to the calling client. i.e. If it is not appropriate to throw an exception in such circumstances how do I indicate to the client that the input integer is an invalid value.

I am asking this question as I am trying to move away (and convince my colleagues to do the same) from using class level error codes.

Thanks in advance,
Nev.

Posted 11-Apr-11 23:50pm

nsimms

Add a Solution

3 solutions

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)

OriginalGriff · Accepted Answer · 2011-04-12T00:01:00

If you don't throw an exception, then there is no standard mechanism for error reporting. You could provide one - before exceptions that was the norm - just provide your method with a bool or int return value.

Exceptions are a better solution though: if a parameter is outside the allowed range it could cause problems in your code later on, so it is better to signal it. It is possible to ignore exceptions (with a empty catch block) but the programmer has to specifically do that, rather than take the easy route of ignoring an error return. Exceptions also allow for range errors in properties, which is very useful!

"Hi OriginalGriff,
Thanks for your response.
So are you saying it's perfectly acceptable to throw an exception in these circumstances. e.g. if we take digital mans code as an example it's acceptable practice to throw new outofrangeexception where he has result = false? This makes sense to me but i have read many posts which state you should not use exceptions to report error which can be programtically checked for."

It is acceptable, yes.
Looking at your communications with digital man, in his code, then he has a mechanism for returning a problem so an exception is not strictly necessary. In your example where the method needs to return an object, the only alternative to an exception is to return a null instead of the object. This will likely cause an exception further down the code, when it is a lot harder to spot the origin of the problem.

My personal opinion is that you should use defensive programming: check your parameters and report problems - via exceptions if necessary - as soon as possible. Exceptions help you to pinpoint them as debug / testing time, rather than waiting until they become a user problem, as you have to specifically ignore them rather than passively by not checking a return code.

The big no-nos as far as I am concerned is using exceptions to control normal execution flow, and using exceptions to handle bad user input. Check what your users enter, don't let it raise exceptions which stop the app!

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-04-12T05:46:00

You should never use "error codes" in replacement of exceptions. Invention of exceptions made all non-exception method obsolete. It needs understanding of exception mechanism which goes above the regular paradigm of methods and calls: it jumps over the stack during propagation. Many do not understand its power and robustness. With error conditions or "codes" you would manually drag it over all your function. In your case, you should really use exceptions. Another reason is separation of concerns. Regular code separate, exceptions separate — that what structured exception handling can do and should not be misused.

There is a long-standing flame war about using exception for non-errors, even here at CodeProject. To me it is absolutely clear, it is possible. That was implied meaning put in the self-describing term "Exception" bt the inventors (Barbara Liskov at all, first applied to the CLU programming language). "Exception" means any exceptional situation. Classic example: "Reactor overheated". Nothing is at fault, but the situation is exceptional, processing is special. The same situation is with the invalid parameter.

You approach should be the Design by contract, see http://en.wikipedia.org/wiki/Design_by_contract[^]. In your case the requirement to stay withing the range 0..10 is called precondition, other components of contract can be postconditions and invariants. An adequate method of processing of violated precondition is throwing exception.

—SA

**R. Giskard Reventlov** · Accepted Answer · 2011-04-11T23:58:00

Solution 1

Very simplistic pseudo code:

public bool MyMethod(int input)
{
    bool result = true;

    if(input < 0 or input > 10)
    {
        // input outside acceptable range.
        result = false;
    }
    else
    {
        // Do whatever you need to with the input.
    }

    return result;
}

You could also take a look at DBC[^].

Posted 11-Apr-11 23:58pm

R. Giskard Reventlov

Updated 12-Apr-11 0:00am

v2

Comments

nsimms 12-Apr-11 6:09am

Thanks for this digital man but this can only be used if the method can return a boolean and not for example if the method needs to return an object. I was looking for a more general/best practice response.

R. Giskard Reventlov 12-Apr-11 6:12am

Er, this was an example: you can return whatever you want! You should also look at implementing DBC: that will give you much of what you are looking for.

Sergey Alexandrovich Kryukov 12-Apr-11 11:51am

This approach is very counter-productive. Sorry. This is a sign of old style from the pre-exception era. The "success" conditions should never be uses. This is a abuse of technology. Only exceptions.
Please see my arguments if you will.
--SA

R. Giskard Reventlov 12-Apr-11 12:44pm

You do talk some nonsense sometimes. He asked for a special case which I supplied. Just because you don't like it... Besides, he should be looking at DBC to solve the problem, not exception handling which is what he wants to avoid plus there is nothing wrong with returning something from a method to denote status or do you think they should all be void?

Sergey Alexandrovich Kryukov 12-Apr-11 15:17pm

No, no, no. This is not because I don't like it. It is a strategic mistake. There is nothing wrong with returning boolean, but it this is a precondition exception should be used. When exception is thrown, return value is not used regardless of return type.

Look, if you think I talk nonsense sometime, you always have a chance to correct me; I always welcome it and sometimes accept and fix myself. This is not the case, because I disagree.

--SA

R. Giskard Reventlov 13-Apr-11 3:24am

Why is everyone ignoring DBC??? (Which would attend to your precondition query). In any case you can't say 'it is a strategic mistake' followed by 'There is nothing wrong with returning boolean'. It is not a mistake: it is a pragmatic coding choice that you make to solve a specific issue. I'm not even saying I would use it (DBC!!!) but there is absolutely nothing wrong with it.

Sergey Alexandrovich Kryukov 13-Apr-11 4:11am

Sorry, disagree. It is ineffective, especially in maintainability.
--SA

R. Giskard Reventlov 13-Apr-11 4:17am

Disagree with which part?
How is that hard to maintain, exactly?

Sergey Alexandrovich Kryukov 13-Apr-11 4:39am

I already explained. If it is called somewhere else which can be successful or not, you need to draw this status all the way through... How about separation of normal code from exceptions, anyway. Exception technology cannot not be replaced because if "jumps over the stack", goes above normal call/return paradigm...
--SA

R. Giskard Reventlov 13-Apr-11 4:56am

You didn't explain anything: you just keep repeating that you don't like it. "If it is called somewhere else which can be successful or not, you need to draw this status all the way through" And what is the problem? If that is what you need to do then do it. You appear to be stuck on some sort of 'this is how it should be done and I won't brook any other way' schtick. Not everything that looks wrong is and not everything that is supposed to be right is. You need to learn to code pragmatically and not just by the book. "Exception technology cannot not be replaced" Says who? You?

Sergey Alexandrovich Kryukov 13-Apr-11 5:14am

Oh, it goes anywhere. I never operated with what I like or not. You know, it needs more room. Yes, I say. This is enough. No matter who say, there is no such thing as authority.
--SA

R. Giskard Reventlov 13-Apr-11 5:19am

"No matter who say, there is no such thing as authority". Now on that we can both agree.

Sergey Alexandrovich Kryukov 13-Apr-11 5:28am

Sure. Look, let's make a break. At our level of disagreement it may need a whole article, set of examples, etc. to argument properly. We're not ready right now, well, I'm certainly not. It needs some serious consideration. I know how to present it, but this format is too limited...
Thank you for discussion.
--SA

R. Giskard Reventlov 13-Apr-11 8:17am

I enjoyed it: thanks.

Albin Abel 12-Apr-11 16:07pm

my 5

Custom Class Exception/Error Handling

3 solutions

Solution 2

Solution 3

Solution 1

Add your solution here

Preview 0