How to handle errors?

[SS]

The following script works fine:

#!/bin/python

import socket

str = raw_input("Enter a domain name: ");
print "Your domain is ", str
print socket.gethostbyname(str)

You provide it a hostname, it provides an IP. That works fine. But I need a way to handle errors. For example:

[root@bart /]# ./dataman.py
Enter a domain name: aslfhafja
Your domain is aslfhafja
Traceback (most recent call last):
File "./dataman.py", line 7, in <module>
print socket.gethostbyname(str)
socket.gaierror: [Errno -2] Name or service not known
[root@bart /]#

I would like to be able to handle that error a bit better. Any ideas?

TIA.

[John Gordon]

In <8500044a-c8d1-43ad...@googlegroups.com> SS <sami....@gmail.com> writes:

> I would like to be able to handle that error a bit better. Any ideas?

Wrap the socket.gethostbyname() call in a try/except block.

--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

[Joaquin Alzola]

> [root@bart /]# ./dataman.py
>Enter a domain name: aslfhafja
>Your domain is aslfhafja
>Traceback (most recent call last):
> File "./dataman.py", line 7, in <module>
> print socket.gethostbyname(str)
>socket.gaierror: [Errno -2] Name or service not known
>[root@bart /]#

>I would like to be able to handle that error a bit better. Any ideas?

Go with the "try ... except ..."

https://docs.python.org/3/tutorial/errors.html
This email is confidential and may be subject to privilege. If you are not the intended recipient, please do not copy or disclose its content but contact the sender immediately upon receipt.

[Steve D'Aprano]

On Fri, 21 Oct 2016 06:48 am, SS wrote:

> The following script works fine:
>
> #!/bin/python
>
> import socket
>
> str = raw_input("Enter a domain name: ");
> print "Your domain is ", str
> print socket.gethostbyname(str)
>
> You provide it a hostname, it provides an IP. That works fine. But I
> need a way to handle errors. For example:

[...]

> I would like to be able to handle that error a bit better. Any ideas?

How do you want to handle the error? You can't just say "handle errors" --
you have to actually decide what do you want to do. If the user provides an
invalid hostname, what do you want to happen? If the network is down, what
do you want to happen?

Sometimes the best way to handle errors is not to handle them at all. If you
don't know what to do with a particular error condition, *don't* handle it.
Let it just go through to the user.




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

[Wildman]

#!/usr/bin/env python

import socket

def get_ip(url):
try:
ip = socket.gethostbyname(url)
return ip
except socket.gaierror:
return "***ERROR***\nUnknown domain name!"

domain = raw_input("Enter a domain name: ");
print "Your domain is ", domain
print get_ip(domain)

--
<Wildman> GNU/Linux user #557453
The cow died so I don't need your bull!

[Wildman]

On Thu, 20 Oct 2016 12:48:28 -0700, SS wrote:

> The following script works fine:
>
> #!/bin/python

I meant to include this with my other post but I forgot it.

Using a direct path to the Python interpreter can cause problems
on some systems because it is not always installed to the same
directory. On my Debian-based system Python is installed in
/usr/bin. So your code as written will not run on my system.
A workaround for this is to use env in the shebang/hashbang.

For Python 2: #!/usr/bin/env python

For Python 3: #!/usr/bin/env python3

It will not matter where Python is installed. 'env' will always
know where it is.

[D'Arcy Cain]

On 2016-10-20 08:03 PM, Wildman via Python-list wrote:
> Using a direct path to the Python interpreter can cause problems
> on some systems because it is not always installed to the same
> directory. On my Debian-based system Python is installed in
> /usr/bin. So your code as written will not run on my system.
> A workaround for this is to use env in the shebang/hashbang.
>
> For Python 2: #!/usr/bin/env python

Which would fail on my system because that's Python 3.5.

> For Python 3: #!/usr/bin/env python3
>
> It will not matter where Python is installed. 'env' will always
> know where it is.

Nothing is perfect. I have just started linking /usr/bin/python* to
wherever the actual one is on all my systems. If I distribute something
I expect the package manager on the target system to rewrite it as
necessary. I use NetBSD pkgsrc (which runs on many systems besides
NetBSD) and it rewrites the HB line.

--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@Vex.Net
VoIP: sip:da...@Vex.Net

[Steve D'Aprano]

On Fri, 21 Oct 2016 11:03 am, Wildman wrote:

> On Thu, 20 Oct 2016 12:48:28 -0700, SS wrote:
>
>> The following script works fine:
>>
>> #!/bin/python
>
> I meant to include this with my other post but I forgot it.
>
> Using a direct path to the Python interpreter can cause problems
> on some systems because it is not always installed to the same
> directory.

Then you change the path and fix it.

> On my Debian-based system Python is installed in
> /usr/bin. So your code as written will not run on my system.
> A workaround for this is to use env in the shebang/hashbang.

That's not a work-around. That's a bug waiting to happen.

One of the problems with of env is that it will use whatever python
executable appears first in the user's $PATH, regardless of whether it is
the right Python or not -- or even whether it is actually Python, or just
some random executable file called "python". For example, you might have
compiled your own experimental Python executable, and adjusted your PATH
environment variable to find it. Now your env scripts will use your
unstable, experimental Python interpreter instead of the system Python.

Another serious problem with using env in the hash-bang line is that you
cannot pass commandline options to the Python executable.

Using env in this way is a hack that happens to mostly work. Its arguably an
abuse of env, and its not as portable as people often think (not all older
Unix systems even have env).

> For Python 2: #!/usr/bin/env python
> For Python 3: #!/usr/bin/env python3
>
> It will not matter where Python is installed. 'env' will always
> know where it is.

That's not correct: env only searches the PATH, so if your python is not in
the path, it won't be found. Here's env on my system with the default PATH:

[steve@ando ~]$ /usr/bin/env python -c "import sys; print(sys.version)"
2.4.3 (#1, Jan 9 2013, 06:49:54)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]


But if I change the search path (or if I move the Python executable
somewhere off the path):

[steve@ando ~]$ PATH="/tmp" /usr/bin/env python -c "import sys;
print(sys.version)"
/usr/bin/env: python: No such file or directory


Even if env finds something called "python", you can't be sure that it is
the right version of Python, or even Python at all. All you know is that it
is something called "python" on the search path.

[Wildman]

On Fri, 21 Oct 2016 16:14:41 +1100, Steve D'Aprano wrote:

> On Fri, 21 Oct 2016 11:03 am, Wildman wrote:
>
>> On Thu, 20 Oct 2016 12:48:28 -0700, SS wrote:
>>
>>> The following script works fine:
>>>
>>> #!/bin/python
>>
>> I meant to include this with my other post but I forgot it.
>>
>> Using a direct path to the Python interpreter can cause problems
>> on some systems because it is not always installed to the same
>> directory.
>
> Then you change the path and fix it.

You are assuming that I, the user, knows what a shebang is and
what it is used for and what Python is and where the interpreter
is located. If you are targeting developers none of that will
be a problem but, if your program is for "average users", you
may have a serious problem. Personally I would not want to
distribute a program that may require the user to fix the code
before it will run.

>> On my Debian-based system Python is installed in
>> /usr/bin. So your code as written will not run on my system.
>> A workaround for this is to use env in the shebang/hashbang.
>
> That's not a work-around. That's a bug waiting to happen.
>
> One of the problems with of env is that it will use whatever python
> executable appears first in the user's $PATH, regardless of whether it is
> the right Python or not -- or even whether it is actually Python, or just
> some random executable file called "python". For example, you might have
> compiled your own experimental Python executable, and adjusted your PATH
> environment variable to find it. Now your env scripts will use your
> unstable, experimental Python interpreter instead of the system Python.

A developer might have complied experimental versions of Python but
the average user will not. Here again it depends on your target.

> Another serious problem with using env in the hash-bang line is that you
> cannot pass commandline options to the Python executable.

Not true. I made a test script with this code:

#!/usr/bin/env python
import sys
print sys.argv

Then I ran it:

~$ python test.py argument1 argument2
['test.py', 'argument1', 'argument2']

> Using env in this way is a hack that happens to mostly work. Its arguably an
> abuse of env, and its not as portable as people often think (not all older
> Unix systems even have env).

If you are targeting older Unixes than yes that could be a problem.

>> For Python 2: #!/usr/bin/env python
>> For Python 3: #!/usr/bin/env python3
>>
>> It will not matter where Python is installed. 'env' will always
>> know where it is.
>
> That's not correct: env only searches the PATH, so if your python is not in
> the path, it won't be found. Here's env on my system with the default PATH:
>
> [steve@ando ~]$ /usr/bin/env python -c "import sys; print(sys.version)"
> 2.4.3 (#1, Jan 9 2013, 06:49:54)
> [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)]
>
>
> But if I change the search path (or if I move the Python executable
> somewhere off the path):
>
> [steve@ando ~]$ PATH="/tmp" /usr/bin/env python -c "import sys;
> print(sys.version)"
> /usr/bin/env: python: No such file or directory
>
>
> Even if env finds something called "python", you can't be sure that it is
> the right version of Python, or even Python at all. All you know is that it
> is something called "python" on the search path.

Not likely an average user is going muck around with the path in
the way you describe.

[John Gordon]

In <D42dnWsQ_pa11pfF...@giganews.com> Wildman <best...@yahoo.com> writes:

> > Another serious problem with using env in the hash-bang line is that you
> > cannot pass commandline options to the Python executable.

> Not true. I made a test script with this code:

> #!/usr/bin/env python
> import sys
> print sys.argv

> Then I ran it:

> ~$ python test.py argument1 argument2
> ['test.py', 'argument1', 'argument2']

Options cannot be passed *on the hash-bang line*.

[Wildman]

On Sat, 22 Oct 2016 15:01:46 +0000, John Gordon wrote:

> In <D42dnWsQ_pa11pfF...@giganews.com> Wildman <best...@yahoo.com> writes:
>
>> > Another serious problem with using env in the hash-bang line is that you
>> > cannot pass commandline options to the Python executable.
>
>> Not true. I made a test script with this code:
>
>> #!/usr/bin/env python
>> import sys
>> print sys.argv
>
>> Then I ran it:
>
>> ~$ python test.py argument1 argument2
>> ['test.py', 'argument1', 'argument2']
>
> Options cannot be passed *on the hash-bang line*.

OK, I misunderstood Steve's statement. I stand corrected.

--
<Wildman> GNU/Linux user #557453

"Well, that's quite different. Never mind."
-Emily Litella

[Bev in TX]

On UNIX type systems, the Python installer creates multiple links to the
actual Python executable. For example in Python 3.5:

python - link to python3.5
python3 - link to python3.5
python3.5 - actual executable

Unless your script specifically requires version 3.5, then it is better
to use the "python3" link, rather than "python3.5". That way your
script would continue to run when you later upgrade to a new version of
Python 3, such as 3.6.

#!/usr/bin/env python3

Bev in TX