[Baypiggies] Python way to avoid usage of raise

[Andy Wiggin]

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
>