Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #112332 > unrolled thread

Python Error message

Started byGBANE FETIGUE <bemen77@gmail.com>
First post2016-08-04 08:31 -0700
Last post2016-08-05 09:03 +0200
Articles 9 — 7 participants

Back to article view | Back to comp.lang.python

Contents

  Python Error message GBANE FETIGUE <bemen77@gmail.com> - 2016-08-04 08:31 -0700
    Re: Python Error message Chris Angelico <rosuav@gmail.com> - 2016-08-05 01:51 +1000
    Re: Python Error message Steven D'Aprano <steve+python@pearwood.info> - 2016-08-05 01:56 +1000
      Re: Python Error message Igor Korot <ikorot01@gmail.com> - 2016-08-04 12:09 -0400
      Re: Python Error message Chris Angelico <rosuav@gmail.com> - 2016-08-05 02:14 +1000
      Re: Python Error message MRAB <python@mrabarnett.plus.com> - 2016-08-04 17:19 +0100
      Re: Python Error message Terry Reedy <tjreedy@udel.edu> - 2016-08-04 15:36 -0400
      Re: Python Error message Chris Angelico <rosuav@gmail.com> - 2016-08-05 05:53 +1000
    Re: Python Error message dieter <dieter@handshake.de> - 2016-08-05 09:03 +0200

#112332 — Python Error message

FromGBANE FETIGUE <bemen77@gmail.com>
Date2016-08-04 08:31 -0700
SubjectPython Error message
Message-ID<710599b6-b8c3-4f5a-a3dd-48757b816a44@googlegroups.com>
Hi, 
I am running a python script to run some CURL commands, and return the response which is the applicationId and the versionId. I was able to do it. Now the versionId value supposed to be used on the second CURL as a value of the applications key which is an array. but it doesn't work.I 'll post the error after running the command as well as the script. It seems like I have an error somewhere because the curl works manually if i run. 

ec2-user@ip-172-31-21-77 playbooks]$ python mmc-uploader.py
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2318    0   119  100  2199    496   9173 --:--:-- --:--:-- --:--:--  9200
Your applicationId is: local$fc9277b0-a5b1-4602-8730-714ab7472744
Your versionId is: local$423da1c8-c4e1-47af-9395-57300f839670
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1259  100  1091  100   168   100k  15868 --:--:-- --:--:-- --:--:--  106k
Final response<!DOCTYPE html><html><head><title>Apache Tomcat/8.0.26 - Error report</title><style type="text/css">H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}.line {height: 1px; background-color: #525D76; border: none;}</style> </head><body><h1>HTTP Status 415 - </h1><div class="line"></div><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server refused this request because the request entity is in a format not supported by the requested resource for the requested method.</u></p><hr class="line"><h3>Apache Tomcat/8.0.26</h3></body></html>
Seems the named id  already exists!

That's the script : 

from subprocess import check_output, STDOUT
import json

response = check_output(["curl", "--basic", "-u", "admin:admin", "-F", "file=@/var/lib/jenkins/workspace/Demo-Ci-cd-automation/playbooks/ms3-simple-hello-world-app-1.0.0-SNAPSHOT.zip", "-F", "name=ms3-simple-hello-world-app", "-F", "version=1.0.0", "--header", "\"Content-Type: multipart/form-data\"", "http://52.73.56.141:8080/mmc-console-3.6.2/api/repository"])


try:
    parsed_response = json.loads(response)
    print "Your applicationId is: " + parsed_response[u'applicationId']
    version_id = parsed_response[u'versionId']
    print "Your versionId is: " + version_id
except:
    print 'Seems the named application already exists!'
    print 'Seems the named versionId already exists!'

response = check_output(["curl", "--basic", "-u", "admin:admin", "-d", "'{\"name\" : \"ms3-simple-hello-world-app\" , \"servers\": [ \"local$d50bdc24-ff04-4327-9284-7bb708e21c25\" ], \"applications\": [ \"" + version_id +  "\"]}'", "--header", "\'Content-Type: application/json\'", "http://52.73.56.141:8080/mmc-console-3.6.2/api/deployments"])

print 'Final response' + response

try:
  parsed_response = json.loads(response)
  deployid  = parsed_response[u'id']
  print "Your deployid is: " + deployid
except:
    print 'Seems the named id  already exists!'

[toc] | [next] | [standalone]

#112333

FromChris Angelico <rosuav@gmail.com>
Date2016-08-05 01:51 +1000
Message-ID<mailman.163.1470325867.6033.python-list@python.org>
In reply to#112332
On Fri, Aug 5, 2016 at 1:31 AM, GBANE FETIGUE <bemen77@gmail.com> wrote:
> try:
>     parsed_response = json.loads(response)
>     print "Your applicationId is: " + parsed_response[u'applicationId']
>     version_id = parsed_response[u'versionId']
>     print "Your versionId is: " + version_id
> except:
>     print 'Seems the named application already exists!'
>     print 'Seems the named versionId already exists!'
>

This is a very bad idea. You're catching every possible exception and
printing out the same message for all of them. And then continuing
blithely on. Instead, catch ONLY the exceptions you really expect to
be seeing (I'm guessing KeyError here). If anything else goes wrong,
let the exception bubble up.

ChrisA

[toc] | [prev] | [next] | [standalone]

#112334

FromSteven D'Aprano <steve+python@pearwood.info>
Date2016-08-05 01:56 +1000
Message-ID<57a36593$0$1590$c3e8da3$5496439d@news.astraweb.com>
In reply to#112332
On Fri, 5 Aug 2016 01:31 am, GBANE FETIGUE wrote:

> try:
>   parsed_response = json.loads(response)
>   deployid  = parsed_response[u'id']
>   print "Your deployid is: " + deployid
> except:
>     print 'Seems the named id  already exists!'


I'm not going to try to debug your code blindfolded with my hands tied
behind my back. Get rid of those "try...except" blocks so that you can see
what error is *actually* happening.

As you have it now, an error happens, somewhere. You don't know where the
error is, or what it is, but Python generates a nice exception showing all
the detail you need to debug.

But you catch that exception, throw it away, and then print a lie.

It is **not true** that the named ID already exists. That is not what the
error is, so why does your script tell a lie?

The output from the server might give you a clue:

"The server refused this request because the request entity is in a format
not supported by the requested resource for the requested method."


Never[1] use a bare "try...except". It is the worst thing you can do to a
Python script, making it almost impossible to debug.

https://realpython.com/blog/python/the-most-diabolical-python-antipattern/

Fix that problem first, get rid of the "try...except" and lying print
messages, and then either the bug will be obvious, or we can debug further.






[1] There are exceptions to this rule, for experts. But if you need to ask
what they are, you're not ready to know.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

[toc] | [prev] | [next] | [standalone]

#112335

FromIgor Korot <ikorot01@gmail.com>
Date2016-08-04 12:09 -0400
Message-ID<mailman.164.1470326982.6033.python-list@python.org>
In reply to#112334
Steven,

On Thu, Aug 4, 2016 at 11:56 AM, Steven D'Aprano
<steve+python@pearwood.info> wrote:
> On Fri, 5 Aug 2016 01:31 am, GBANE FETIGUE wrote:
>
>> try:
>>   parsed_response = json.loads(response)
>>   deployid  = parsed_response[u'id']
>>   print "Your deployid is: " + deployid
>> except:
>>     print 'Seems the named id  already exists!'
>
>
> I'm not going to try to debug your code blindfolded with my hands tied
> behind my back. Get rid of those "try...except" blocks so that you can see
> what error is *actually* happening.
>
> As you have it now, an error happens, somewhere. You don't know where the
> error is, or what it is, but Python generates a nice exception showing all
> the detail you need to debug.
>
> But you catch that exception, throw it away, and then print a lie.
>
> It is **not true** that the named ID already exists. That is not what the
> error is, so why does your script tell a lie?
>
> The output from the server might give you a clue:
>
> "The server refused this request because the request entity is in a format
> not supported by the requested resource for the requested method."
>
>
> Never[1] use a bare "try...except". It is the worst thing you can do to a
> Python script, making it almost impossible to debug.
>
> https://realpython.com/blog/python/the-most-diabolical-python-antipattern/
>
> Fix that problem first, get rid of the "try...except" and lying print
> messages, and then either the bug will be obvious, or we can debug further.
>
>
>
>
>
>
> [1] There are exceptions to this rule, for experts. But if you need to ask
> what they are, you're not ready to know

But even the experts will never write such a code - you never know what happens
in a month. Server might throw some new exception, you may move on to
a different project,
etc, etc. ;-)

Thank you.

>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#112336

FromChris Angelico <rosuav@gmail.com>
Date2016-08-05 02:14 +1000
Message-ID<mailman.166.1470327290.6033.python-list@python.org>
In reply to#112334
On Fri, Aug 5, 2016 at 2:09 AM, Igor Korot <ikorot01@gmail.com> wrote:
>> [1] There are exceptions to this rule, for experts. But if you need to ask
>> what they are, you're not ready to know
>
> But even the experts will never write such a code - you never know what happens
> in a month. Server might throw some new exception, you may move on to
> a different project,
> etc, etc. ;-)

Yes, in those situations you don't write a bare except :) As Steven
said, there ARE legit uses; most of them fall under the description
"boundary location".

ChrisA

[toc] | [prev] | [next] | [standalone]

#112337

FromMRAB <python@mrabarnett.plus.com>
Date2016-08-04 17:19 +0100
Message-ID<mailman.167.1470327601.6033.python-list@python.org>
In reply to#112334
On 2016-08-04 17:09, Igor Korot wrote:
> Steven,
>
> On Thu, Aug 4, 2016 at 11:56 AM, Steven D'Aprano
> <steve+python@pearwood.info> wrote:
>> On Fri, 5 Aug 2016 01:31 am, GBANE FETIGUE wrote:
>>
>>> try:
>>>   parsed_response = json.loads(response)
>>>   deployid  = parsed_response[u'id']
>>>   print "Your deployid is: " + deployid
>>> except:
>>>     print 'Seems the named id  already exists!'
>>
>>
>> I'm not going to try to debug your code blindfolded with my hands tied
>> behind my back. Get rid of those "try...except" blocks so that you can see
>> what error is *actually* happening.
>>
>> As you have it now, an error happens, somewhere. You don't know where the
>> error is, or what it is, but Python generates a nice exception showing all
>> the detail you need to debug.
>>
>> But you catch that exception, throw it away, and then print a lie.
>>
>> It is **not true** that the named ID already exists. That is not what the
>> error is, so why does your script tell a lie?
>>
>> The output from the server might give you a clue:
>>
>> "The server refused this request because the request entity is in a format
>> not supported by the requested resource for the requested method."
>>
>>
>> Never[1] use a bare "try...except". It is the worst thing you can do to a
>> Python script, making it almost impossible to debug.
>>
>> https://realpython.com/blog/python/the-most-diabolical-python-antipattern/
>>
>> Fix that problem first, get rid of the "try...except" and lying print
>> messages, and then either the bug will be obvious, or we can debug further.
>>
>>
>>
>>
>>
>>
>> [1] There are exceptions to this rule, for experts. But if you need to ask
>> what they are, you're not ready to know
>
> But even the experts will never write such a code - you never know what happens
> in a month. Server might throw some new exception, you may move on to
> a different project,
> etc, etc. ;-)
>
In those rare occasions when you do write a bare except, you'd re-raise 
the exception afterwards:

try:
     ...
except:
     print("'tis but a scratch!")
     raise

> Thank you.
>

[toc] | [prev] | [next] | [standalone]

#112348

FromTerry Reedy <tjreedy@udel.edu>
Date2016-08-04 15:36 -0400
Message-ID<mailman.176.1470339425.6033.python-list@python.org>
In reply to#112334
On 8/4/2016 12:19 PM, MRAB wrote:

> In those rare occasions when you do write a bare except,

A bare "except:" is never needed and in my opinion, and that of others, 
one should never write one (except possibly for experimentation). Be 
explicit and write "except BaseException:" or "except Exception:", 
whichever one is the actual intent.

 > you'd re-raise the exception afterwards:

As a general rule, this is wrong, just as this rule is wrong for other 
exception blocks.

> try:
>     ...
> except:
>     print("'tis but a scratch!")
>     raise

This is right when one wants to do something *in addition to* the normal 
handling, such as log errors to a file, but is wrong when wants to do 
something *instead of* allowing the normal handling.

An example of the latter is when one writes code in Python to execute 
'other' code.  (IDLE is one example.  It both executes user statements 
and evals user expressions.)  One needs "except BaseException:"  to 
isolate the interpreter from exceptions raised in the interpreted code. 
(It would be wrong for IDLE to stop because a user submitted code that 
raises, whether intentionally or accidentally)  A 'raise' that throws 
the exception into the interpreter is likely the worst thing to do.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#112350

FromChris Angelico <rosuav@gmail.com>
Date2016-08-05 05:53 +1000
Message-ID<mailman.178.1470340412.6033.python-list@python.org>
In reply to#112334
On Fri, Aug 5, 2016 at 5:36 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> An example of the latter is when one writes code in Python to execute
> 'other' code.  (IDLE is one example.  It both executes user statements and
> evals user expressions.)  One needs "except BaseException:"  to isolate the
> interpreter from exceptions raised in the interpreted code. (It would be
> wrong for IDLE to stop because a user submitted code that raises, whether
> intentionally or accidentally)  A 'raise' that throws the exception into the
> interpreter is likely the worst thing to do.

This is a classic example of a "boundary location". Another extremely
common example is a web server: if an exception bubbles out of a
request handler function, the outer wrapper code should catch that,
log it, and send a 500 back to the client.

But none of this is what the OP is doing.

ChrisA

[toc] | [prev] | [next] | [standalone]

#112371

Fromdieter <dieter@handshake.de>
Date2016-08-05 09:03 +0200
Message-ID<mailman.187.1470380608.6033.python-list@python.org>
In reply to#112332
GBANE FETIGUE <bemen77@gmail.com> writes:
> ...
> I am running a python script to run some CURL commands, and return the response which is the applicationId and the versionId. I was able to do it. Now the versionId value supposed to be used on the second CURL as a value of the applications key which is an array. but it doesn't work.I 'll post the error after running the command as well as the script. It seems like I have an error somewhere because the curl works manually if i run. 
>
> ec2-user@ip-172-31-21-77 playbooks]$ python mmc-uploader.py
> ...
> Final response<!DOCTYPE html><html>...<body><h1>HTTP Status 415 - </h1><div class="
>  line"></div><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server refused this request because the request entity is in a format not supported by the reque
>  sted resource for the requested method.</u></p><hr class="line"><h3>Apache Tomcat/8.0.26</h3></body></html>

What you see here is *not* a Python error message but an
error message from the server you have contacted.
It tells you:
"The server refused this request because the request entity is in a format not supported by the requested resource for the requested method."

This means, that in constructing your request you made some error - regarding
the "format" (which may mean the "Content-Type") for
the request "entity" (which may mean the request body).

I would check the service description to find out about what
"format" is expected and what the term "entity" means.
Then I would check the "curl" documentation to find out how to meet
those expectations.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web