SPUG: Advice on sub return-code policies?

Fred Morris 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 


Fred Morris

More information about the spug-list mailing list