I have a number of custom exceptions created for my Django project. like so
errors.py
# General Exceptions
class VersionError(Exception):
pass
class ParseError(Exception):
pass
class ConfigError(Exception):
pass
class InstallError(Exception):
pass
However I want to print the output from my custom exceptions but not the general. But do not want to list them all out, i.e
try:
do something wrong
except <custom errors>, exc:
print exc
except:
print "Gen
Canonical way would be to create common superclass for all your exceptions.
# General Exceptions
class MyAppError(Exception):
pass
class VersionError(MyAppError):
pass
class ParseError(MyAppError):
pass
class ConfigError(MyAppError):
pass
class InstallError(MyAppError):
pass
With this inheritance three you may simply catch all exceptions of type MyAppError.
try:
do_something()
except MyAppError as e:
print e
You could make a tuple of the exceptions:
my_exceptions = (VersionError,
ParseError,
ConfigError,
InstallError)
Usage:
except my_exceptions as exception:
print exception
e.g:
>>> my_exceptions = (LookupError, ValueError, TypeError)
>>> try:
... int('a')
... except my_exceptions as exception:
... print type(exception)
... print exception
<type 'exceptions.ValueError'>
invalid literal for int() with base 10: 'a'
You should define a custom marker base class for your custom exceptions:
# General Exceptions
class MyException(Exception):
"""Just a marker base class"""
class VersionError(MyException):
pass
class ParseError(MyException):
pass
class ConfigError(MyException):
pass
class InstallError(MyException):
pass
With that modification, you can then easily say:
try:
do something wrong
except MyException as exc:
print exc
except:
print "Some other generic exception was raised"
(BTW, you should use the recommended except Exception as ex syntax instead of the except Exception, ex, see this question for details)
You should make a common base class for all your custom exceptions, and catch that.
Create a custom base exception and derive all the other custom exceptions form this base execption:
class CustomBaseException(Exception):
pass
# General Exceptions
class VersionError(CustomBaseException):
pass
class ParseError(CustomBaseException):
pass
class ConfigError(CustomBaseException):
pass
class InstallError(CustomBaseException):
pass
Then you can do
try:
do something wrong
except CustomBaseExecption, exc:
print exc
except:
print "Gen
Related
Instead of calling the exception directly, I have seen it is subclassed with nothing in it or a pass statement. How does it help Python internally to subclass a base class, in this manner? Does it change namespace or signature? How?
class ACustomException(Exception):
pass
class BCustomException(Exception):
pass
Raising Exception is like telling the doctor "Something's wrong" and then refusing to answer any questions. Compare:
try:
with open("foo.json", "rt") as r:
new_count = json.load(r)["count"] + 1
except Exception:
# Is the file missing?
# Is the file there, but not readable?
# Is the file readable, but does not contain valid JSON?
# Is the file format okay, but the data's not a dict with `count`?
# Is the entry `count` there, but is not a number?
print("Something's wrong")
# I don't care. You figure it out.
and
try:
with open("data.json", "rt") as r:
new_count = json.load(r)["count"] + 1
except FileNotFoundError:
print("File is missing.")
except PermissionError:
print("File not readable.")
except json.decoder.JSONDecoderError:
print("File is not valid JSON.")
except KeyError:
print("Cannot find count.")
except TypeError:
print("Count is not a number.")
If you are making a library, you can use the predefined exception classes where appropriate — but sometimes you need to communicate errors that Python creators never thought about, or you need to make a finer distinction than the existing exceptions do. This is when you'd create a custom exception.
For example, Django will define django.contrib.auth.models.User.DoesNotExist exception to communicate that the code tried to look for a User in the database, but no User matching the given criteria could be found. Being able to catch django.contrib.auth.models.User.DoesNotExist is like being a doctor, and getting a patient that not only tells you what hurts, but brings X-rays and a printed family history with them.
When you're handling exceptions with try-except, you're catching them by name, so having specific names helps you handle them.
For example, if a function raises Exception for any error, the catching logic gets complicated:
def foobar():
if FOO:
raise Exception('FOO happened')
elif BAR:
raise Exception('BAR happened')
try:
foobar()
except Exception as e:
if e.args == ('FOO happened',):
print('Handling FOO')
elif e.args == ('BAR happened',):
print('Handling BAR')
else:
raise
On the other hand if you have subclassed exceptions, the catching logic is simple:
class FooError(Exception):
pass
class BarError(Exception):
pass
def function():
if FOO:
raise FooError('FOO happened')
elif BAR:
raise BarError('BAR happened')
try:
function()
except FooError:
print('Handling FOO')
except BarError:
print('Handling BAR')
It helps with determining 'what' the traceback issue is referring to in case of maybe a web service that you maybe running, so it's not low-level or the generic errors you normally get back rather the exception class that would be used.
To be more specific with an example:
val = int(input('Enter a number:'))
try:
val *= val
except ValueError as e:
raise e
print(val)
### ValueError will be raised if user inputs something other than a number
### this raise e will return the actual error message saying
### ValueError: invalid literal for int() with base 10: 'ok'
In your case, you could still raise your exception keeping ValueError as the except to be handled for, like this:
val = int(input('Enter a number:'))
try:
val *= val
except ValueError as e:
raise ACustomException('some debug statement referring to the cause of the error')
print(val)
### now this will raise your exception class besides the ValueError exception, with a debug statement if you choose to have one in it.
If I have a code that raises more exceptions simultaniously like this
class A(Exception): pass
class B(Exception): pass
try:
try:
raise A('first')
finally:
raise B('second')
except X as c:
print(c)
Is there a way for handle all the exceptions toghether?
You can handle them all in this way:
except (A, B) as c:
Also you can define your own base class for your exceptions:
class BaseCustomException(Exception): pass
class A(BaseCustomException): pass
class B(BaseCustomException): pass
After it you can catch base exception, it will cover all derived exceptions:
except BaseCustomException as c:
When an new exception is thrown in a catch block or finally block that will propagate out of that block, then the current exception will be aborted (and forgotten) as the new exception is propagated outward. The new exception starts unwinding up the stack just like any other exception, aborting out of the current block (the catch or finally block) and subject to any applicable catch or finally blocks along the way.
check:Exception thrown in catch and finally clause
I have a project that I need to run and have no idea how to implement custom exceptions. It mostly does complicated scientific functions, to be vague.
Mostly it will be raising exceptions if something is not set. I've been given this as a starting example from runnables.
# Define a class inherit from an exception type
class CustomError(Exception):
def __init__(self, arg):
# Set some exception infomation
self.msg = arg
try:
# Raise an exception with argument
raise CustomError('This is a CustomError')
except CustomError, arg:
# Catch the custom exception
print 'Error: ', arg.msg
I have no idea how this is meant to work or how I am meant to implement my code. It's not very explicit.
To give an idea of a basic exception that needs created.
In a function:
if self.humidities is None:
print "ERROR: Humidities have not been set..."
return
Apparently this needs to raise/throw an exception instead.
A ValueError looks suitable for your humidities example.
if self.humidities is None:
raise ValueError('Humidities value required')
If you want to be specific:
class HumiditiesError(Exception):
pass
def set_humidities(humidities):
if humidities is None:
raise HumiditiesError('Value required')
try:
set_humidities(None)
except HumiditiesError as e:
print 'Humidities error:', e.message
This defines a subclass of Exception named HumiditiesError. The default behavior seems sufficient for your example, so the body of the class is empty (pass) as no additional nor modified functionality is required.
N.B. Python 2 assumed. In Python 3 you would access elements of the e.args tuple.
What is a good way of raising sub-exceptions (is that's the term)?
Scenario:
I want to raise a custom ConnectivityException when http or ftp exception occurs. Is there any way to raise ConnectivityException such that exceptions are categorized properly (i.e. I should be able to tell if ConnectivityException is raised because of http ot ftp)?
A standard technique would be to subclass ConnectivityException to create exception classes specific to each kind of error condition:
class ConnectivityException(Exception): pass
class HTTPConnectivityException(ConnectivityException): pass
class FTPConnectivityException(ConnectivityException): pass
Then instead of raise ConnectivityException you can use raise HTTPConnectivityException or raise FTPConnectivityException, depending on which specific type of error you want to indicate.
Multiple exception blocks can be used to dispatch error handling according to the exception type:
try:
some_network_operation()
except HTTPConnectivityException as ex:
# This will execute if the error is an HTTPConnectivityException.
except FTPConnectivityException as ex:
# Likewise for FTPConnectivityException.
except ConnectivityException as ex:
# The generic case; this block will execute if the ConnectivityException isn't
# an instance of one of the earlier specified subclasses.
Note that the exception-handling blocks are tried in lexical order; the first block specifying a class to which the exception object belongs will be used. In this case, that means that you need to put the ConnectivityException block last, or else it will catch HTTPConnectivityException and FTPConnectivityException as well.
you can add an attribute named 'source' to ConnectivityException, and set it to 'http' or 'ftp' according to specific situation, when catch ConnectivityException, check the source attribute and decide what to do
here i recommend another way which uses inherit class
class ConnectivityException(Exception):
pass # you can define some attributes and methods, here I just escape
class HTTPConnectivityException(ConnectivityException):
pass
class FTPConnectivityException(ConnectivityException):
pass
def func():
if some_condition:
raise HTTPConnectivityException()
if some_other_condition:
raise FTPConnectivityException()
def another_func():
try:
func()
except HTTPConnectivityException as e:
pass # you can do something here
except FTPConnectivityException as e:
pass
In a code where there are different old-style classes like this one:
class customException: pass
and exceptions are raised this way:
raise customException()
Is there a type to catch all those old-style class exceptions? like this:
try:
...
except EXCEPTION_TYPE as e:
#do something with e
Or at least is there a way to catch everything (old- and new-style) and get the exception object in a variable?
try:
...
except:
#this catches everything but there is no exception variable
The only solution I can think of is using sys.exc_info
import sys
try:
raise customException()
except:
e = sys.exc_info()[1]
# handle exception "e" here...