Re(5): Idomatic Handling of Subroutine Error

If you need a useful return value upon success, you're having that one function do too many things at once.

A function should do one and only one thing, and do it well. It should be simple enough that you can know what's going on simply due to success or failure. Maybe, you need failure to give you more than one option. Hence, the option I suggested above.

Try and refactor your function so that if it succeeds, that's all the info you need. If you cannot, make it into an object similar to what btrott said in direct response to your original node.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re(5): Idomatic Handling of Subroutine Error

Replies are listed 'Best First'.
Re: Re(5): Idomatic Handling of Subroutine Error by dvergin (Monsignor) on Sep 19, 2001 at 01:24 UTC
I appreciate your original suggestion and your bringing the focus to bear on 'first principles'. I understand and support the principle of cohesion. We may differ on the application of that principle to this case. I submit that "give me a value or tell me why you failed" is sufficiently cohesive and a useful job description for a subroutine. Granted, it is not Functional Cohesion in the strictest sense. But I think it is a common, intuitive, and effective way to foster clear program flow at the level of the call. I agree with your comment on btrott's submission and have /msg'ed him to say so. Since my app is already OO, it is the approach I intend to use in this case. But not every program is OO and I was simply wanting to build on your very helpful suggestion and see if it might be possible to extend that idea to allow a useful return value while factoring out the wrapper subroutine. My question (and it's about time for me to stop yacking and run some test scripts) is whether the `eval {die "error description"}` trick will work and allow me to access $@ back at the call level. Thanks again for this exchange. David	[reply]

Replies are listed 'Best First'.

Re: Re(5): Idomatic Handling of Subroutine Error
by dvergin (Monsignor) on Sep 19, 2001 at 01:24 UTC

We may differ on the application of that principle to this case. I submit that "give me a value or tell me why you failed" is sufficiently cohesive and a useful job description for a subroutine. Granted, it is not Functional Cohesion in the strictest sense. But I think it is a common, intuitive, and effective way to foster clear program flow at the level of the call.

I agree with your comment on btrott's submission and have /msg'ed him to say so. Since my app is already OO, it is the approach I intend to use in this case.

But not every program is OO and I was simply wanting to build on your very helpful suggestion and see if it might be possible to extend that idea to allow a useful return value while factoring out the wrapper subroutine.

My question (and it's about time for me to stop yacking and run some test scripts) is whether the eval {die "error description"} trick will work and allow me to access $@ back at the call level.

Thanks again for this exchange. David

[reply]