[bop-devel] quick fix for LinkPoint.pm

[Jo Rhett]

On Fri, January 19, 2007 11:32 am, Ivan Kohler wrote:
> This is the intended behavior.  From "notes_for_module_writers_v3":

Gotcha, but ...

> Use eval { } to trap these sort of "out-of-band" errors and handle them
> differently than normal declines.

Hm.  Invalid credit card expiration is not a setup problem, this is normal
feedback that should be returned to the user.  I would agree if say, I
couldn't read the certificate file that a special error code may apply.

As to your suggestion -- Eval the invocation of every BOP function call?
Perhaps I'm being old fashioned, but isn't this creating lots of extra
code for no particular gain that I can see?  And doesn't it prevent the
return of useful data?  For instance, I can't check {ERROR} status after
exiting the eval block, can I?

If there is a clueful way to do this that doesn't cause problems I'm all
ears.  But eval() has always been more trouble than it's worth.  I usually
mark "eval()" to mean that the library is sloppy and should be
rewritten...

> Now, that said, I'm totally up for changing how we do our error
> handling, but we'd have to define what the change is first, not just start
> patching processor modules inconsistently.  :)
>
> I do think it is important to distinguish between these sorts of errors
> and errors that come back from the processor, not just set is_success to 0.
> I'm not particularly attached to the whole die/croak think if folks
> would prefer some sort of special return instead.

If croak could be captured usefully, I wouldn't object so much.  But I
think that returning an error result and setting a variable (or two)
containing the error message would be better.

And I say "two" because I feel that listing the specific fields that the
processor had a problem with could be used to provide very useful
responses to the end user.

-- 
Jo Rhett
Network/Software Engineer
Net Consonance