Re: OOP style question: Checking a value

Actually, it seems a bit behind the curve already. As in, by the time I'm looking at the response code, I should already know whether we are looking at an error or not. So, checking against OK seems a bit late.

if (not $client->foo({some=> 'args'}))
{
    my $rc = $client->get_current_error();
    # handle the error ... no need to check "OK".
}
[download]

Now, as to what the current error might be, I don't know. Most of the time, I keep my functions and methods trivial enough that true/false is sufficient. I know that doesn't work in all cases (DBI springs to mind). That said, I'm not really fond of numbers - they're way too opaque. Figuring out what return code 3618 is is not what I want to do every time I call foo. So I kinda like it when the error is a string that I can just display. For example, if you had a set_current_error method that took a string, set the internal marker to that string, and also took a stack trace and stored that, and then I could query for the error message, or I could query for the stack trace of the error (or one after the other). Both can come in handy. (Carp's longmess may come in handy for creating the stack trace).

Also, by using strings, you don't need constants anymore. A simple true/false for the method's success, and a string for the error. Seems straightforward to me.

(Yes, I can see how more information about a failure could be handy, and thus the reason for error objects, but that can be overkill in some projects. I don't know if this is such a project.)

Comment on Re: OOP style question: Checking a value Download Code

Replies are listed 'Best First'.
Re^2: OOP style question: Checking a value by spq (Friar) on Aug 29, 2006 at 21:32 UTC
Arggg - shouldn't have used OK in my OP I guess. Please see my response to the previous reply as well. I certainly agree that 'Figuring out what return code 3618 is' is a pain. Which is why I originally exported constants, such as ERROR, OK, NOT_FOUND, BAD_REQUEST, FORBIDDEN etc. Each method is (well, mostly will-be ;) documented with the possible codes it might set, should you be interested in finding out more details. This allowed things like: `# load test client $client = new MyModule({CLIENT_ID => 0}) ok($client && $client->response_code == CREATED, 'Loaded test client'); # foo test case 1 my $goodies = $client->foo({some => 'args'}); ok(defined $goodies && $client->response_code == OK, 'Got some kind of goodies from foo');` [download] That's an example of the current API in a couple tests, checking response codes. Now, normally you would never need to do this in production code; if $client was actually a true value, then the client should have loaded fine and your object should be good to go. Hopefully the $goodies you get back, if any, are the goodies you want. If not, then you might want to go get the error message(s) (such as you would for DBI) or perhaps even determine the specific response code. But now I'm participating in wandering off the subject. - lol - Let me try rewording my question. Lets assume that a side-effect of calling methods on an object of class Bar is that it changes the value of one of the objects attributes. The possible values are meaningful for some purpose and not arbitrary, only being selected from a limited, well defined set of possible values. While these values could be anything (numbers, documents, other objects), checking which value it is set to can be accomplished by comparing it to a defined set of English words - mnemonics. In the original version these words were exported from a central repository (that hides any magic away) and could be checked against the current state with `== SOME_WORD`. However, I want to combine a few things that are related and go together well with these word definitions and make them a class of their own, which my other classes may inherit from. This makes it 'impossible' to export the words as before, and as such alternate syntax's need to be considered.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: OOP style question: Checking a value
by spq (Friar) on Aug 29, 2006 at 21:32 UTC

Arggg - shouldn't have used OK in my OP I guess. Please see my response to the previous reply as well. I certainly agree that 'Figuring out what return code 3618 is' is a pain. Which is why I originally exported constants, such as ERROR, OK, NOT_FOUND, BAD_REQUEST, FORBIDDEN etc. Each method is (well, mostly will-be ;) documented with the possible codes it might set, should you be interested in finding out more details. This allowed things like:

# load test client
$client = new MyModule({CLIENT_ID => 0})
ok($client && $client->response_code == CREATED,
    'Loaded test client');

# foo test case 1
my $goodies = $client->foo({some => 'args'});
ok(defined $goodies && $client->response_code == OK,
    'Got some kind of goodies from foo');
[download]

That's an example of the current API in a couple tests, checking response codes. Now, normally you would never need to do this in production code; if $client was actually a true value, then the client should have loaded fine and your object should be good to go. Hopefully the $goodies you get back, if any, are the goodies you want. If not, then you might want to go get the error message(s) (such as you would for DBI) or perhaps even determine the specific response code.

But now I'm participating in wandering off the subject. - lol - Let me try rewording my question. Lets assume that a side-effect of calling methods on an object of class Bar is that it changes the value of one of the objects attributes. The possible values are meaningful for some purpose and not arbitrary, only being selected from a limited, well defined set of possible values. While these values could be anything (numbers, documents, other objects), checking which value it is set to can be accomplished by comparing it to a defined set of English words - mnemonics. In the original version these words were exported from a central repository (that hides any magic away) and could be checked against the current state with == SOME_WORD. However, I want to combine a few things that are related and go together well with these word definitions and make them a class of their own, which my other classes may inherit from. This makes it 'impossible' to export the words as before, and as such alternate syntax's need to be considered.

[reply]
[d/l]
[select]