SPUG: Advice on sub return-code policies?
m3047 at inwa.net
Thu Oct 5 17:00:51 PDT 2006
In the present case, I think I'd reframe that as "what advice would you offer
to the consultant in a situation like this"? Ok, ok, levity aside...
Is the distinction between "sub" and "function" real or carelessness with
language? Avoid being careless with language!
On Wednesday 04 October 2006 14:42, Tim Maher wrote:
> [...] every sub needs
> to return a standardized "error code".
> [...] like chain functions together (as
> in reverse sort keys)?
> An "out-of-band" delivery mechanism would seem to be needed, but it
> would have to be sophisticated enough to be usable with multi-
> threaded apps, and no too inefficient. Are there any CPAN modules
> that can help?
eval() is your friend; of course, you know this. ;-) You might have to put a
wrapper around stuff to make it conform.
If simply writing results into a hashref (I'm sure there's some way to get at
the guts of what is Perl and put keys in the hashref which are tied to the
subroutine names) isn't sturdy enough, seems to me you could cook up
something akin to a parse tree, and use it to accumulate and track the
"useful" output of subroutines.
> What advice would you offer to a client like this?
Keeping with the reframing, can they cogently explain what they really mean,
and are they cognizant of the limitations of this paradigm? You ought to get
paid to work through this with them, if they don't have a solid
I would want to explore if there was room for a distinction between functions
which return useful function results, and subroutines which can be overloaded
to return an error code. You'd have to "sandbox" the functions and aggregate
any errors which occured in them, I suppose.
Would I recommend this as a good approach? While the individual practices
might have utility in certain situations, as a package deal to comply with
some hidebound and unexamined corporate policy... I'd examine the policy
More information about the spug-list