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