[Baypiggies] Python way to avoid usage of raise

[Andy Wiggin]

Right. I couldn't get past that part either, at least based on what I
know about coding in pure python. When we did this in C of course we
used macros to wrap the standard return-on-error-of-child behavior and
every now and then wrote something more sophisticated (oh! Just like
an exception, except with extra text obscuring the code). So short of
using a macro-preprocessor to generate your python files, you can at
least standardize and condense the one-liner after each function call.
Here's what I came up with:


class FuncStatus:
    def __init__(self, success, payload):
        self.success = success
        self.payload = payload
    def err(self):
        return not self.success

def sub_test(v):
    if v > 0:
        return FuncStatus(True, "a b c")
    else:
        return FuncStatus(False, ["d", "e", "f"])

def main():
    #if (s = sub_test(-2)).err() return s
    s = sub_test(2)
    if s.err(): return s
    print "Hey 1", s.payload

    s = sub_test(-2)
    if s.err(): return s
    print "Hey 2", s.payload

main()

-Andy

On Tue, Oct 5, 2010 at 10:32 PM, Nick S Kanakakorn <bbdada at gmail.com> wrote:
> Hi Andy,
> Thanks for your comment.  I could wrap this in a class but I'm not so sure
> how it would save me to have to do something like this.
> class ReturnWrapper(object):
>      def __init__(error_code, error_message, real_return_result)
>            ....
> def f1(arg):
>     try
>         x = some_function()
>     except IndexError, e
>         return ReturnWrapper(-1,'some error message' , None)
>     # all good here
>     return ReturnWrapper(0, None, 'some good value')
> def f1caller()
>     obj = f1(param1)
>     if (obj.error_code < 0):
>        # handle some error or just return obj
>        return obj
>     foo....
>     obj = f1(param2)
>     if (obj.error_code < 0):
>        # handle some error or just return obj
>        return obj
>     bar....
>
> I still have to use this pattern     if (obj.error_code < 0):  ....
> It does not really make my code smaller than using tuple.
> I used to code C similar to what you said I did not expect to have to do
> the
> same thing in python
> Thanks,
> On Tue, Oct 5, 2010 at 9:42 PM, Andy Wiggin <andywiggin at gmail.com> wrote:
>>
>> I must agree with the "it's an unmitigated disaster" comments already
>> posted. But it does remind me of a C coding convention that was the
>> standard at a company worked at a long time ago. Here, the return
>> value from a function was always a coded int value where part of the
>> int told you the boolean pass/fail info, part encoded the severity,
>> part the product id, and part the specific message that could be
>> looked up to print. All packed into 32 bits. The analogy I can think
>> of is that you might want to return an instance of a standard class
>> instead of a raw tuple. It could have pass/fail info, perhaps more
>> extended info, plus a generic "payload" that would carry whatever the
>> function was really trying to return. This would at least save you
>> from interpreting ad hoc tuples everywhere, and might be a basis for
>> building something a bit more elegant.
>>
>> -Andy
>>
>> On Tue, Oct 5, 2010 at 9:16 PM, Nick S Kanakakorn <bbdada at gmail.com>
>> wrote:
>> > I don't want to do this.  There is someone that against throwing
>> > exception
>> > and that person has more seniority than me. He put in a guideline.  I
>> > lost
>> > in the debate.  There is no proper research done and all the decisions
>> > were
>> > made in less than 1 day.
>> >
>> > On Tue, Oct 5, 2010 at 9:03 PM, Tung Wai Yip <tungwaiyip at yahoo.com>
>> > wrote:
>> >>
>> >> Why do you want to do this? Is this just an internal coding guideline?
>> >> Or
>> >> is it done for interfacing to another language or running on
>> >> non-standard
>> >> VM? Is this apply to new code only or do you want to update existing
>> >> code as
>> >> well?
>> >>
>> >> There is no equivalent of C macro in Python. Just apply every code
>> >> change
>> >> as you describe it. Build a tuple every time you return something.
>> >> Change
>> >> raise into returning tuple. And change ever function call to expecting
>> >> a
>> >> tuple return value. I can't think of anything smarter. it looks like a
>> >> complete disaster anyway.
>> >>
>> >> Wai yip
>> >>
>> >>
>> >>
>> >>> Let's skip the rationale discussion although I feel better for your
>> >>> sympathy.  One non python solution I can think of is Macro (C/C++) or
>> >>> add
>> >>> a
>> >>> new command  which could work in any stack frame (TCL).
>> >>> However, I'm quite new to python so I'm not so sure if there are some
>> >>> ways
>> >>> around this.
>> >>>
>> >>> Can we have something similar to macro in python ?
>> >>>
>> >>> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <glen at glenjarvis.com>
>> >>> wrote:
>> >>>
>> >>>>
>> >>>> > My work place has imposed a rules for no use of exception (catching
>> >>>> > is
>> >>>> allowed).
>> >>>>
>> >>>> What?!?
>> >>>>
>> >>>> Forgive my reaction, I'm just very surprised. Why has your workplace
>> >>>> implemented this policy? Has anyone else on BayPIGgies seen a  policy
>> >>>> like
>> >>>> this? What's the rationale?  Am I a Luddite for not hearing on this?
>> >>>>
>> >>>> I'm sorry. I know you asked a genuine question and I haven't answered
>> >>>> it. I
>> >>>> just found this very odd and am first getting my head around the
>> >>>> question.
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>>
>> >>>> Glen
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>> >> _______________________________________________
>> >> Baypiggies mailing list
>> >> Baypiggies at python.org
>> >> To change your subscription options or unsubscribe:
>> >> http://mail.python.org/mailman/listinfo/baypiggies
>> >
>> >
>> >
>> > --
>> > -Nick Kanakakorn
>> >
>> > _______________________________________________
>> > Baypiggies mailing list
>> > Baypiggies at python.org
>> > To change your subscription options or unsubscribe:
>> > http://mail.python.org/mailman/listinfo/baypiggies
>> >
>
>
>
> --
> -Nick Kanakakorn
>