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.
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).if (not $client->foo({some=> 'args'})) { my $rc = $client->get_current_error(); # handle the error ... no need to check "OK". }
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.)
In reply to Re: OOP style question: Checking a value
by Tanktalus
in thread OOP style question: Checking a value
by spq
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |