Class-wide exception handler - python

I would like to implement a way to globally handle exceptions in a class coming through my application rather than handle them at the call site because it will cause a lot of duplicate code.
For example's sake say I have a class like so:
class handler():
def throws_value_error(self):
raise ValueError
def throws_not_implemented_error(self):
raise NotImplementedError
# ... Imagine there are hundreds of these
In this handler class I'd like all ValueError and NotImplementedError handled the same way - a message saying [ERROR]: ... where ... is the details from the particular instance.
Instead of reproducing a TON of:
try:
#...
except Exception as e:
# Catch the instances of the exception and handle them
# in more-or-less the same way here
I'd like to have a single method implementable on the class that takes care of this in general:
def exception_watcher(self):
# Big if...elif...else for handling these types of exceptions
Then, this method would be invoked when any Exception inside the class is given.
My motivation is to use this to implement a generic sort of controller interface where a controller method could throw a subclass of an exception (for example - BadRequestException which is subclassed from Error400Exception). From there, the handler could dispatch a method to properly configure a response with an error code tailored to the type of exception, and additionally return a useful reply to the consumer.
Obviously this is doable without this dispatcher - but this way certainly saves a ton of duplicated code (and therefore bugs).
I've done a lot of digging around the internet and I haven't found anything. Admittedly I am borrowing this pattern from the Spring Boot Framework. I will also accept this being non-pythonic as an answer (as long as you can tell me how to do it right!)
Any help would be appreciated - thank you!


Modifying functions without altering their core functionality is exactly what decorators are for. Take a look at this example and try running it:
def catch_exception(func):
def wrapped(self, *args, **kwargs):
try:
return func(self, *args, **kwargs)
except ValueError:
self.value_error_handler()
except NotImplementedError:
self.ni_error_handler()
return wrapped
class Handler:
def value_error_handler(self):
print("found value error")
def ni_error_handler(self):
print("found not implemented error")
#catch_exception
def value_error_raiser(self):
raise ValueError
#catch_exception
def ni_error_raiser(self):
raise NotImplementedError
h = Handler()
h.value_error_raiser()
h.ni_error_raiser()
Because of the #catch_exception decorator, the decorated methods do not raise the errors shown when caled; instead, they call the respective method defined inside wrapped's try/except block, printing a message.
While this is not exactly what you asked for, I believe this solution is more manageable overall. You can both choose exactly what methods should raise exceptions regularly and which should be handled by catch_exception (by deciding which methods are decorated), and add future behaviour for other exception types by writing an extra except block inside wrapped and adding the respective method to the Handler class.
Note that this is not a "clean" solution, since wrapped expects to know that self is an instance of Handler, seeing as it calls a bunch of its methods, even though it is a function outside the Handler class... But hey, that's Python's duck typing for you :-P

Related

Proper way of making a Python file with custom exceptions [duplicate]

What's the proper way to declare custom exception classes in modern Python? My primary goal is to follow whatever standard other exception classes have, so that (for instance) any extra string I include in the exception is printed out by whatever tool caught the exception.
By "modern Python" I mean something that will run in Python 2.5 but be 'correct' for the Python 2.6 and Python 3.* way of doing things. And by "custom" I mean an Exception object that can include extra data about the cause of the error: a string, maybe also some other arbitrary object relevant to the exception.
I was tripped up by the following deprecation warning in Python 2.6.2:
>>> class MyError(Exception):
... def __init__(self, message):
... self.message = message
...
>>> MyError("foo")
_sandbox.py:3: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
It seems crazy that BaseException has a special meaning for attributes named message. I gather from PEP-352 that attribute did have a special meaning in 2.5 they're trying to deprecate away, so I guess that name (and that one alone) is now forbidden? Ugh.
I'm also fuzzily aware that Exception has some magic parameter args, but I've never known how to use it. Nor am I sure it's the right way to do things going forward; a lot of the discussion I found online suggested they were trying to do away with args in Python 3.
Update: two answers have suggested overriding __init__, and __str__/__unicode__/__repr__. That seems like a lot of typing, is it necessary?

Maybe I missed the question, but why not:
class MyException(Exception):
pass
To override something (or pass extra args), do this:
class ValidationError(Exception):
def __init__(self, message, errors):
# Call the base class constructor with the parameters it needs
super().__init__(message)
# Now for your custom code...
self.errors = errors
That way you could pass dict of error messages to the second param, and get to it later with e.errors.
In Python 2, you have to use this slightly more complex form of super():
super(ValidationError, self).__init__(message)

With modern Python Exceptions, you don't need to abuse .message, or override .__str__() or .__repr__() or any of it. If all you want is an informative message when your exception is raised, do this:
class MyException(Exception):
pass
raise MyException("My hovercraft is full of eels")
That will give a traceback ending with MyException: My hovercraft is full of eels.
If you want more flexibility from the exception, you could pass a dictionary as the argument:
raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
However, to get at those details in an except block is a bit more complicated. The details are stored in the args attribute, which is a list. You would need to do something like this:
try:
raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
except MyException as e:
details = e.args[0]
print(details["animal"])
It is still possible to pass in multiple items to the exception and access them via tuple indexes, but this is highly discouraged (and was even intended for deprecation a while back). If you do need more than a single piece of information and the above method is not sufficient for you, then you should subclass Exception as described in the tutorial.
class MyError(Exception):
def __init__(self, message, animal):
self.message = message
self.animal = animal
def __str__(self):
return self.message

"What is the proper way to declare custom exceptions in modern Python?"
This is fine unless your exception is really a type of a more specific exception:
class MyException(Exception):
pass
Or better (maybe perfect), instead of pass give a docstring:
class MyException(Exception):
"""Raise for my specific kind of exception"""
Subclassing Exception Subclasses
From the docs
Exception
All built-in, non-system-exiting exceptions are derived from this class.
All user-defined exceptions should also be derived from this
class.
That means that if your exception is a type of a more specific exception, subclass that exception instead of the generic Exception (and the result will be that you still derive from Exception as the docs recommend). Also, you can at least provide a docstring (and not be forced to use the pass keyword):
class MyAppValueError(ValueError):
'''Raise when my specific value is wrong'''
Set attributes you create yourself with a custom __init__. Avoid passing a dict as a positional argument, future users of your code will thank you. If you use the deprecated message attribute, assigning it yourself will avoid a DeprecationWarning:
class MyAppValueError(ValueError):
'''Raise when a specific subset of values in context of app is wrong'''
def __init__(self, message, foo, *args):
self.message = message # without this you may get DeprecationWarning
# Special attribute you desire with your Error,
# perhaps the value that caused the error?:
self.foo = foo
# allow users initialize misc. arguments as any other builtin Error
super(MyAppValueError, self).__init__(message, foo, *args)
There's really no need to write your own __str__ or __repr__. The built-in ones are very nice, and your cooperative inheritance ensures that you use them.
Critique of the top answer
Maybe I missed the question, but why not:
class MyException(Exception):
pass
Again, the problem with the above is that in order to catch it, you'll either have to name it specifically (importing it if created elsewhere) or catch Exception, (but you're probably not prepared to handle all types of Exceptions, and you should only catch exceptions you are prepared to handle). Similar criticism to the below, but additionally that's not the way to initialize via super, and you'll get a DeprecationWarning if you access the message attribute:
Edit: to override something (or pass extra args), do this:
class ValidationError(Exception):
def __init__(self, message, errors):
# Call the base class constructor with the parameters it needs
super(ValidationError, self).__init__(message)
# Now for your custom code...
self.errors = errors
That way you could pass dict of error messages to the second param, and get to it later with e.errors
It also requires exactly two arguments to be passed in (aside from the self.) No more, no less. That's an interesting constraint that future users may not appreciate.
To be direct - it violates Liskov substitutability.
I'll demonstrate both errors:
>>> ValidationError('foo', 'bar', 'baz').message
Traceback (most recent call last):
File "<pyshell#10>", line 1, in <module>
ValidationError('foo', 'bar', 'baz').message
TypeError: __init__() takes exactly 3 arguments (4 given)
>>> ValidationError('foo', 'bar').message
__main__:1: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
'foo'
Compared to:
>>> MyAppValueError('foo', 'FOO', 'bar').message
'foo'

see how exceptions work by default if one vs more attributes are used (tracebacks omitted):
>>> raise Exception('bad thing happened')
Exception: bad thing happened
>>> raise Exception('bad thing happened', 'code is broken')
Exception: ('bad thing happened', 'code is broken')
so you might want to have a sort of "exception template", working as an exception itself, in a compatible way:
>>> nastyerr = NastyError('bad thing happened')
>>> raise nastyerr
NastyError: bad thing happened
>>> raise nastyerr()
NastyError: bad thing happened
>>> raise nastyerr('code is broken')
NastyError: ('bad thing happened', 'code is broken')
this can be done easily with this subclass
class ExceptionTemplate(Exception):
def __call__(self, *args):
return self.__class__(*(self.args + args))
# ...
class NastyError(ExceptionTemplate): pass
and if you don't like that default tuple-like representation, just add __str__ method to the ExceptionTemplate class, like:
# ...
def __str__(self):
return ': '.join(self.args)
and you'll have
>>> raise nastyerr('code is broken')
NastyError: bad thing happened: code is broken

As of Python 3.8 (2018, https://docs.python.org/dev/whatsnew/3.8.html), the recommended method is still:
class CustomExceptionName(Exception):
"""Exception raised when very uncommon things happen"""
pass
Please don't forget to document, why a custom exception is neccessary!
If you need to, this is the way to go for exceptions with more data:
class CustomExceptionName(Exception):
"""Still an exception raised when uncommon things happen"""
def __init__(self, message, payload=None):
self.message = message
self.payload = payload # you could add more args
def __str__(self):
return str(self.message) # __str__() obviously expects a string to be returned, so make sure not to send any other data types
and fetch them like:
try:
raise CustomExceptionName("Very bad mistake.", "Forgot upgrading from Python 1")
except CustomExceptionName as error:
print(str(error)) # Very bad mistake
print("Detail: {}".format(error.payload)) # Detail: Forgot upgrading from Python 1
payload=None is important to make it pickle-able. Before dumping it, you have to call error.__reduce__(). Loading will work as expected.
You maybe should investigate in finding a solution using pythons return statement if you need much data to be transferred to some outer structure. This seems to be clearer/more pythonic to me. Advanced exceptions are heavily used in Java, which can sometimes be annoying, when using a framework and having to catch all possible errors.

To define your own exceptions correctly, there are a few best practices that you should follow:
Define a base class inheriting from Exception. This will allow to easily catch any exceptions related to the project:
class MyProjectError(Exception):
"""A base class for MyProject exceptions."""
Organizing the exception classes in a separate module (e.g. exceptions.py) is generally a good idea.
To create a specific exception, subclass the base exception class.
class CustomError(MyProjectError):
"""A custom exception class for MyProject."""
You can subclass custom exception classes as well to create a hierarchy.
To add support for extra argument(s) to a custom exception, define an __init__() method with a variable number of arguments. Call the base class's __init__(), passing any positional arguments to it (remember that BaseException/Exception expect any number of positional arguments). Store extra keyword arguments to the instance, e.g.:
class CustomError(MyProjectError):
def __init__(self, *args, **kwargs):
super().__init__(*args)
self.custom_kwarg = kwargs.get('custom_kwargs')
Usage example:
try:
raise CustomError('Something bad happened', custom_kwarg='value')
except CustomError as exc:
print(f'Сaught CustomError exception with custom_kwarg={exc.custom_kwarg}')
This design adheres to the Liskov substitution principle, since you can replace an instance of a base exception class with an instance of a derived exception class. Also, it allows you to create an instance of a derived class with the same parameters as the parent.

You should override __repr__ or __unicode__ methods instead of using message, the args you provide when you construct the exception will be in the args attribute of the exception object.

See a very good article "The definitive guide to Python exceptions". The basic principles are:
Always inherit from (at least) Exception.
Always call BaseException.__init__ with only one argument.
When building a library, define a base class inheriting from Exception.
Provide details about the error.
Inherit from builtin exceptions types when it makes sense.
There is also information on organizing (in modules) and wrapping exceptions, I recommend to read the guide.

No, "message" is not forbidden. It's just deprecated. You application will work fine with using message. But you may want to get rid of the deprecation error, of course.
When you create custom Exception classes for your application, many of them do not subclass just from Exception, but from others, like ValueError or similar. Then you have to adapt to their usage of variables.
And if you have many exceptions in your application it's usually a good idea to have a common custom base class for all of them, so that users of your modules can do
try:
...
except NelsonsExceptions:
...
And in that case you can do __init__ and __str__ needed there, so you don't have to repeat it for every exception. But simply calling the message variable something else than message does the trick.
In any case, you only need __init__ or __str__ if you do something different from what Exception itself does. And because if the deprecation, you then need both, or you get an error. That's not a whole lot of extra code you need per class.

For maximum customisation, to define custom errors, you may want to define an intermediate class that inherits from Exception class as:
class BaseCustomException(Exception):
def __init__(self, msg):
self.msg = msg
def __repr__(self):
return self.msg
class MyCustomError(BaseCustomException):
"""raise my custom error"""

Try this Example
class InvalidInputError(Exception):
def __init__(self, msg):
self.msg = msg
def __str__(self):
return repr(self.msg)
inp = int(input("Enter a number between 1 to 10:"))
try:
if type(inp) != int or inp not in list(range(1,11)):
raise InvalidInputError
except InvalidInputError:
print("Invalid input entered")

A really simple approach:
class CustomError(Exception):
pass
raise CustomError("Hmm, seems like this was custom coded...")
Or, have the error raise without printing __main__ (may look cleaner and neater):
class CustomError(Exception):
__module__ = Exception.__module__
raise CustomError("Improved CustomError!")

I had issues with the above methods, as of Python 3.9.5.
However, I found that this works for me:
class MyException(Exception):
"""Port Exception"""
And then it could be used in code like:
try:
raise MyException('Message')
except MyException as err:
print (err)

I came across this thread. This is how I do custom exceptions. While the Fault class is slightly complex, it makes declaring custom expressive exceptions with variable arguments trivial.
FinalViolation, SingletonViolation are both sub classes of TypeError so will be caught code below.
try:
<do something>
except TypeError as ex:
<handler>
That's why Fault doesn't inherit from Exception. To allow derivative exceptions to inherit from the exception of their choice.
class Fault:
"""Generic Exception base class. Note not descendant of Exception
Inheriting exceptions override formats"""
formats = '' # to be overriden in descendant classes
def __init__(self, *args):
"""Just save args for __str__"""
self.args = args
def __str__(self):
"""Use formats declared in descendant classes, and saved args to build exception text"""
return self.formats.format(*self.args)
class TypeFault(Fault, TypeError):
"""Helper class mixing Fault and TypeError"""
class FinalViolation(TypeFault):
"""Custom exception raised if inheriting from 'final' class"""
formats = "type {} is not an acceptable base type. It cannot be inherited from."
class SingletonViolation(TypeFault):
"""Custom exception raised if instancing 'singleton' class a second time"""
formats = "type {} is a singleton. It can only be instanced once."
FinalViolation, SingletonViolation unfortunately only accept 1 argument.
But one could easily create a multi arg error e.g.
class VesselLoadingError(Fault, BufferError):
formats = "My {} is full of {}."
raise VesselLoadingError('hovercraft', 'eels')
__main__.VesselLoadingError: My hovercraft is full of eels.

For me it is just __init__ and variables but making sometimes testing.
My sample:
Error_codes = { 100: "Not enough parameters", 101: "Number of special characters more than limits", 102: "At least 18 alphanumeric characters and list of special chars !##$&*" }
class localbreak( Exception ) :
Message = ""
def __init__(self, Message):
self.Message = Message
return
def __str__(self):
print(self.Message)
return "False"
### When calling ...
raise localbreak(Error_codes[102])
Output:
Traceback (most recent call last): File "ASCII.py", line 150, in <module>
main(OldPassword, Newpassword) File "ASCII.py", line 39, in main
result = read_input("1", "2", Newpassword, "4")
File "ASCII.py", line 69, in read_input
raise localbreak(Error_codes[102]) At least 18 alphanumeric characters and list of special chars !##$&*
__main__.localbreak: False

How to correctly process arguments to avoid raising an Exception? [duplicate]

What's the proper way to declare custom exception classes in modern Python? My primary goal is to follow whatever standard other exception classes have, so that (for instance) any extra string I include in the exception is printed out by whatever tool caught the exception.
By "modern Python" I mean something that will run in Python 2.5 but be 'correct' for the Python 2.6 and Python 3.* way of doing things. And by "custom" I mean an Exception object that can include extra data about the cause of the error: a string, maybe also some other arbitrary object relevant to the exception.
I was tripped up by the following deprecation warning in Python 2.6.2:
>>> class MyError(Exception):
... def __init__(self, message):
... self.message = message
...
>>> MyError("foo")
_sandbox.py:3: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
It seems crazy that BaseException has a special meaning for attributes named message. I gather from PEP-352 that attribute did have a special meaning in 2.5 they're trying to deprecate away, so I guess that name (and that one alone) is now forbidden? Ugh.
I'm also fuzzily aware that Exception has some magic parameter args, but I've never known how to use it. Nor am I sure it's the right way to do things going forward; a lot of the discussion I found online suggested they were trying to do away with args in Python 3.
Update: two answers have suggested overriding __init__, and __str__/__unicode__/__repr__. That seems like a lot of typing, is it necessary?

Maybe I missed the question, but why not:
class MyException(Exception):
pass
To override something (or pass extra args), do this:
class ValidationError(Exception):
def __init__(self, message, errors):
# Call the base class constructor with the parameters it needs
super().__init__(message)
# Now for your custom code...
self.errors = errors
That way you could pass dict of error messages to the second param, and get to it later with e.errors.
In Python 2, you have to use this slightly more complex form of super():
super(ValidationError, self).__init__(message)

With modern Python Exceptions, you don't need to abuse .message, or override .__str__() or .__repr__() or any of it. If all you want is an informative message when your exception is raised, do this:
class MyException(Exception):
pass
raise MyException("My hovercraft is full of eels")
That will give a traceback ending with MyException: My hovercraft is full of eels.
If you want more flexibility from the exception, you could pass a dictionary as the argument:
raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
However, to get at those details in an except block is a bit more complicated. The details are stored in the args attribute, which is a list. You would need to do something like this:
try:
raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
except MyException as e:
details = e.args[0]
print(details["animal"])
It is still possible to pass in multiple items to the exception and access them via tuple indexes, but this is highly discouraged (and was even intended for deprecation a while back). If you do need more than a single piece of information and the above method is not sufficient for you, then you should subclass Exception as described in the tutorial.
class MyError(Exception):
def __init__(self, message, animal):
self.message = message
self.animal = animal
def __str__(self):
return self.message

"What is the proper way to declare custom exceptions in modern Python?"
This is fine unless your exception is really a type of a more specific exception:
class MyException(Exception):
pass
Or better (maybe perfect), instead of pass give a docstring:
class MyException(Exception):
"""Raise for my specific kind of exception"""
Subclassing Exception Subclasses
From the docs
Exception
All built-in, non-system-exiting exceptions are derived from this class.
All user-defined exceptions should also be derived from this
class.
That means that if your exception is a type of a more specific exception, subclass that exception instead of the generic Exception (and the result will be that you still derive from Exception as the docs recommend). Also, you can at least provide a docstring (and not be forced to use the pass keyword):
class MyAppValueError(ValueError):
'''Raise when my specific value is wrong'''
Set attributes you create yourself with a custom __init__. Avoid passing a dict as a positional argument, future users of your code will thank you. If you use the deprecated message attribute, assigning it yourself will avoid a DeprecationWarning:
class MyAppValueError(ValueError):
'''Raise when a specific subset of values in context of app is wrong'''
def __init__(self, message, foo, *args):
self.message = message # without this you may get DeprecationWarning
# Special attribute you desire with your Error,
# perhaps the value that caused the error?:
self.foo = foo
# allow users initialize misc. arguments as any other builtin Error
super(MyAppValueError, self).__init__(message, foo, *args)
There's really no need to write your own __str__ or __repr__. The built-in ones are very nice, and your cooperative inheritance ensures that you use them.
Critique of the top answer
Maybe I missed the question, but why not:
class MyException(Exception):
pass
Again, the problem with the above is that in order to catch it, you'll either have to name it specifically (importing it if created elsewhere) or catch Exception, (but you're probably not prepared to handle all types of Exceptions, and you should only catch exceptions you are prepared to handle). Similar criticism to the below, but additionally that's not the way to initialize via super, and you'll get a DeprecationWarning if you access the message attribute:
Edit: to override something (or pass extra args), do this:
class ValidationError(Exception):
def __init__(self, message, errors):
# Call the base class constructor with the parameters it needs
super(ValidationError, self).__init__(message)
# Now for your custom code...
self.errors = errors
That way you could pass dict of error messages to the second param, and get to it later with e.errors
It also requires exactly two arguments to be passed in (aside from the self.) No more, no less. That's an interesting constraint that future users may not appreciate.
To be direct - it violates Liskov substitutability.
I'll demonstrate both errors:
>>> ValidationError('foo', 'bar', 'baz').message
Traceback (most recent call last):
File "<pyshell#10>", line 1, in <module>
ValidationError('foo', 'bar', 'baz').message
TypeError: __init__() takes exactly 3 arguments (4 given)
>>> ValidationError('foo', 'bar').message
__main__:1: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
'foo'
Compared to:
>>> MyAppValueError('foo', 'FOO', 'bar').message
'foo'

see how exceptions work by default if one vs more attributes are used (tracebacks omitted):
>>> raise Exception('bad thing happened')
Exception: bad thing happened
>>> raise Exception('bad thing happened', 'code is broken')
Exception: ('bad thing happened', 'code is broken')
so you might want to have a sort of "exception template", working as an exception itself, in a compatible way:
>>> nastyerr = NastyError('bad thing happened')
>>> raise nastyerr
NastyError: bad thing happened
>>> raise nastyerr()
NastyError: bad thing happened
>>> raise nastyerr('code is broken')
NastyError: ('bad thing happened', 'code is broken')
this can be done easily with this subclass
class ExceptionTemplate(Exception):
def __call__(self, *args):
return self.__class__(*(self.args + args))
# ...
class NastyError(ExceptionTemplate): pass
and if you don't like that default tuple-like representation, just add __str__ method to the ExceptionTemplate class, like:
# ...
def __str__(self):
return ': '.join(self.args)
and you'll have
>>> raise nastyerr('code is broken')
NastyError: bad thing happened: code is broken

As of Python 3.8 (2018, https://docs.python.org/dev/whatsnew/3.8.html), the recommended method is still:
class CustomExceptionName(Exception):
"""Exception raised when very uncommon things happen"""
pass
Please don't forget to document, why a custom exception is neccessary!
If you need to, this is the way to go for exceptions with more data:
class CustomExceptionName(Exception):
"""Still an exception raised when uncommon things happen"""
def __init__(self, message, payload=None):
self.message = message
self.payload = payload # you could add more args
def __str__(self):
return str(self.message) # __str__() obviously expects a string to be returned, so make sure not to send any other data types
and fetch them like:
try:
raise CustomExceptionName("Very bad mistake.", "Forgot upgrading from Python 1")
except CustomExceptionName as error:
print(str(error)) # Very bad mistake
print("Detail: {}".format(error.payload)) # Detail: Forgot upgrading from Python 1
payload=None is important to make it pickle-able. Before dumping it, you have to call error.__reduce__(). Loading will work as expected.
You maybe should investigate in finding a solution using pythons return statement if you need much data to be transferred to some outer structure. This seems to be clearer/more pythonic to me. Advanced exceptions are heavily used in Java, which can sometimes be annoying, when using a framework and having to catch all possible errors.

To define your own exceptions correctly, there are a few best practices that you should follow:
Define a base class inheriting from Exception. This will allow to easily catch any exceptions related to the project:
class MyProjectError(Exception):
"""A base class for MyProject exceptions."""
Organizing the exception classes in a separate module (e.g. exceptions.py) is generally a good idea.
To create a specific exception, subclass the base exception class.
class CustomError(MyProjectError):
"""A custom exception class for MyProject."""
You can subclass custom exception classes as well to create a hierarchy.
To add support for extra argument(s) to a custom exception, define an __init__() method with a variable number of arguments. Call the base class's __init__(), passing any positional arguments to it (remember that BaseException/Exception expect any number of positional arguments). Store extra keyword arguments to the instance, e.g.:
class CustomError(MyProjectError):
def __init__(self, *args, **kwargs):
super().__init__(*args)
self.custom_kwarg = kwargs.get('custom_kwargs')
Usage example:
try:
raise CustomError('Something bad happened', custom_kwarg='value')
except CustomError as exc:
print(f'Сaught CustomError exception with custom_kwarg={exc.custom_kwarg}')
This design adheres to the Liskov substitution principle, since you can replace an instance of a base exception class with an instance of a derived exception class. Also, it allows you to create an instance of a derived class with the same parameters as the parent.

You should override __repr__ or __unicode__ methods instead of using message, the args you provide when you construct the exception will be in the args attribute of the exception object.

See a very good article "The definitive guide to Python exceptions". The basic principles are:
Always inherit from (at least) Exception.
Always call BaseException.__init__ with only one argument.
When building a library, define a base class inheriting from Exception.
Provide details about the error.
Inherit from builtin exceptions types when it makes sense.
There is also information on organizing (in modules) and wrapping exceptions, I recommend to read the guide.

No, "message" is not forbidden. It's just deprecated. You application will work fine with using message. But you may want to get rid of the deprecation error, of course.
When you create custom Exception classes for your application, many of them do not subclass just from Exception, but from others, like ValueError or similar. Then you have to adapt to their usage of variables.
And if you have many exceptions in your application it's usually a good idea to have a common custom base class for all of them, so that users of your modules can do
try:
...
except NelsonsExceptions:
...
And in that case you can do __init__ and __str__ needed there, so you don't have to repeat it for every exception. But simply calling the message variable something else than message does the trick.
In any case, you only need __init__ or __str__ if you do something different from what Exception itself does. And because if the deprecation, you then need both, or you get an error. That's not a whole lot of extra code you need per class.

For maximum customisation, to define custom errors, you may want to define an intermediate class that inherits from Exception class as:
class BaseCustomException(Exception):
def __init__(self, msg):
self.msg = msg
def __repr__(self):
return self.msg
class MyCustomError(BaseCustomException):
"""raise my custom error"""

Try this Example
class InvalidInputError(Exception):
def __init__(self, msg):
self.msg = msg
def __str__(self):
return repr(self.msg)
inp = int(input("Enter a number between 1 to 10:"))
try:
if type(inp) != int or inp not in list(range(1,11)):
raise InvalidInputError
except InvalidInputError:
print("Invalid input entered")

A really simple approach:
class CustomError(Exception):
pass
raise CustomError("Hmm, seems like this was custom coded...")
Or, have the error raise without printing __main__ (may look cleaner and neater):
class CustomError(Exception):
__module__ = Exception.__module__
raise CustomError("Improved CustomError!")

I had issues with the above methods, as of Python 3.9.5.
However, I found that this works for me:
class MyException(Exception):
"""Port Exception"""
And then it could be used in code like:
try:
raise MyException('Message')
except MyException as err:
print (err)

I came across this thread. This is how I do custom exceptions. While the Fault class is slightly complex, it makes declaring custom expressive exceptions with variable arguments trivial.
FinalViolation, SingletonViolation are both sub classes of TypeError so will be caught code below.
try:
<do something>
except TypeError as ex:
<handler>
That's why Fault doesn't inherit from Exception. To allow derivative exceptions to inherit from the exception of their choice.
class Fault:
"""Generic Exception base class. Note not descendant of Exception
Inheriting exceptions override formats"""
formats = '' # to be overriden in descendant classes
def __init__(self, *args):
"""Just save args for __str__"""
self.args = args
def __str__(self):
"""Use formats declared in descendant classes, and saved args to build exception text"""
return self.formats.format(*self.args)
class TypeFault(Fault, TypeError):
"""Helper class mixing Fault and TypeError"""
class FinalViolation(TypeFault):
"""Custom exception raised if inheriting from 'final' class"""
formats = "type {} is not an acceptable base type. It cannot be inherited from."
class SingletonViolation(TypeFault):
"""Custom exception raised if instancing 'singleton' class a second time"""
formats = "type {} is a singleton. It can only be instanced once."
FinalViolation, SingletonViolation unfortunately only accept 1 argument.
But one could easily create a multi arg error e.g.
class VesselLoadingError(Fault, BufferError):
formats = "My {} is full of {}."
raise VesselLoadingError('hovercraft', 'eels')
__main__.VesselLoadingError: My hovercraft is full of eels.

For me it is just __init__ and variables but making sometimes testing.
My sample:
Error_codes = { 100: "Not enough parameters", 101: "Number of special characters more than limits", 102: "At least 18 alphanumeric characters and list of special chars !##$&*" }
class localbreak( Exception ) :
Message = ""
def __init__(self, Message):
self.Message = Message
return
def __str__(self):
print(self.Message)
return "False"
### When calling ...
raise localbreak(Error_codes[102])
Output:
Traceback (most recent call last): File "ASCII.py", line 150, in <module>
main(OldPassword, Newpassword) File "ASCII.py", line 39, in main
result = read_input("1", "2", Newpassword, "4")
File "ASCII.py", line 69, in read_input
raise localbreak(Error_codes[102]) At least 18 alphanumeric characters and list of special chars !##$&*
__main__.localbreak: False

How to capture exception thrown by class definnition in python 2.7

I've go code like that:
class Foo:
foo_const = function_which_throws_something()
How to capture such exception? Is it possible at all?

IMHO, execution of a function that can raise exceptions at definition time is a questionable design. It is of course allowed by Python language because a def statement is executable, but it does not improve readability.
My advice would be to execute the function later, after the class definition:
# definition
class Foo:
foo_const = None # default initialization in case of problem...
#classmethod
def init_foo(cls):
cls.foo_const = function_which_throws_something()
# initialization
try:
Foo.init_foo()
except:
# process the exceptional condition
...
That way, the class is always constructed, you can simply process the exception and the const has a default value.
But if you want to produce shorter even if IMO less intelligible code, you could do:
try:
class Foo:
foo_const = function_which_throws_something()
except:
class Foo:
foo_const = None
# further exception processing
...
Above code uses raw except to catch any exception which should be avoided, if only SomeException can be thrown, you should use:
try:
...
except SomeException: # or except SomeException as e:
...

Yes, it is possible. Just wrap the class definition with try-except statements:
def some_func():
raise Exception('some exception')
try:
class X:
y = some_func()
except Exception as e:
print 'Got it!', e
Executing the code above prints:
Got it! some exception

I would do it this way, minimizing the code that can throw an exception inside the try - except block.
def throw_exception():
raise Exception('exc')
class Foo(object):
try:
x = throw_exception()
except Exception as exc:
x = 'Exception was thrown: {}'.format(exc)
>>> Foo.x
'Exception was thrown: exc'
This code will always create the class, and the variable value depends on the function. If an exception happens, it captures it and edit the value.

In python everything except compilation to bytecode happens at runtime. IOW, class is an executable statement. When the interpreter reaches a class statement, it sets up a namespace, execute the whole class statement's body within that namespace, and uses all names defined in that namespace to use as class attributes. Then it calls type() with the class name, bases and the collected namespaces, and binds the newly created class object (instance of type or whatever custom metaclass) to the class name.
This means that you can execute any arbitrary code within the class statement - try/except, loops, conditionals, just whatever legit Python code, including, as in your example, calling a function. And actually in your case it's not the "class definition" that raises an exception but the function you call from within the class statement, so you can obviously wrap the call in a try/except block if it makes sense for you concrete problem (cf at the end of this answer).
Now for what happens if you don't handle the error at all: assuming your class statement is at the module's top level (not nested in a function), the exception will fire when the runtime executes the script or module containing the class definition. If the containing file is used as a module (=> imported from another place) - which is the most likely - this will happen on the first import of the module, be catched by the python runtime, and replaced by an ImportError, so you won't be able to properly handle the case from the importing code.
Obviously the best solution here is to avoid having any exception here, and if you cannot avoid it make sure you log the full exception (message & traceback) from within the class statement's body itself so you get a hint of why the import fails:
import logging
logger = logging.getLogger(__name__)
class Foo(object):
try:
myconst = some_func_that_raises()
except Exception as e:
logger.exception("failed to initialize Foo.my_const : %s", e)
# let's not pretend otherwise : something failed and we cannot
# fix it here
raise
Now the real questions are: why does this function raise, can properly you recover from this exception (in a way that won't break the client code later I mean), and do you really need to call it at this point ? How to properly handle your case actually depends on those points

Monkey Patching Exception class and other builtin classes

Regardless of the Excpetion type, I would like to print a message whenever an exception occurs.
I tried the following:
class MyException(BaseException):
def __init__(self, msg):
super(BaseException, self).__init__(msg)
print "Howdy", msg
__builtins__.Exception = MyException
try:
raise IOError("world")
except Exception as e:
pass
I expected "Howdy world" to be printed but instead I get nothing.
EDIT:
#helmut suggested using sys.settrace, the following code works as expected.
import sys
def trace(frame, event, arg):
print event
return trace
sys.settrace(trace)
def foo():
raise Exception()
def bar():
foo()
def baz():
try:
bar()
except:
pass
baz()
exit()
Too bad this is too slow for my use case.

Why not monkey-patch?
Let me explain why the projected approach is flawed. What happens when you assign MyException to Exception is that you change the global variable Exception within this module. All exception classes defined before this assignment or in different modules will not use it. They will use the original value instead. Since IOError is created during interpreter startup, your assignment has no effect on it. So if you were to monkey-patch the Exception class you would be overriding its methods. Most importantly you would be changing its __init__ and __new__ methods. Unfortunately that method is not supported and changing those attributes results in:
TypeError: can't set attributes of built-in/extension type 'exceptions.Exception'
So the approach to monkey-patch the interpreter will likely not work out.
Alternative: tracing
An alternative would be to write a function to be passed to sys.settrace. It is invoked for each function call and should return another tracing function if the particular call is to be traced. Various events are passed to the latter tracing function and one of them is 'exception'. By filtering on those events you may already achieve the intended effect.

Proper way to declare custom exceptions in modern Python?

What's the proper way to declare custom exception classes in modern Python? My primary goal is to follow whatever standard other exception classes have, so that (for instance) any extra string I include in the exception is printed out by whatever tool caught the exception.
By "modern Python" I mean something that will run in Python 2.5 but be 'correct' for the Python 2.6 and Python 3.* way of doing things. And by "custom" I mean an Exception object that can include extra data about the cause of the error: a string, maybe also some other arbitrary object relevant to the exception.
I was tripped up by the following deprecation warning in Python 2.6.2:
>>> class MyError(Exception):
... def __init__(self, message):
... self.message = message
...
>>> MyError("foo")
_sandbox.py:3: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
It seems crazy that BaseException has a special meaning for attributes named message. I gather from PEP-352 that attribute did have a special meaning in 2.5 they're trying to deprecate away, so I guess that name (and that one alone) is now forbidden? Ugh.
I'm also fuzzily aware that Exception has some magic parameter args, but I've never known how to use it. Nor am I sure it's the right way to do things going forward; a lot of the discussion I found online suggested they were trying to do away with args in Python 3.
Update: two answers have suggested overriding __init__, and __str__/__unicode__/__repr__. That seems like a lot of typing, is it necessary?

Maybe I missed the question, but why not:
class MyException(Exception):
pass
To override something (or pass extra args), do this:
class ValidationError(Exception):
def __init__(self, message, errors):
# Call the base class constructor with the parameters it needs
super().__init__(message)
# Now for your custom code...
self.errors = errors
That way you could pass dict of error messages to the second param, and get to it later with e.errors.
In Python 2, you have to use this slightly more complex form of super():
super(ValidationError, self).__init__(message)

With modern Python Exceptions, you don't need to abuse .message, or override .__str__() or .__repr__() or any of it. If all you want is an informative message when your exception is raised, do this:
class MyException(Exception):
pass
raise MyException("My hovercraft is full of eels")
That will give a traceback ending with MyException: My hovercraft is full of eels.
If you want more flexibility from the exception, you could pass a dictionary as the argument:
raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
However, to get at those details in an except block is a bit more complicated. The details are stored in the args attribute, which is a list. You would need to do something like this:
try:
raise MyException({"message":"My hovercraft is full of animals", "animal":"eels"})
except MyException as e:
details = e.args[0]
print(details["animal"])
It is still possible to pass in multiple items to the exception and access them via tuple indexes, but this is highly discouraged (and was even intended for deprecation a while back). If you do need more than a single piece of information and the above method is not sufficient for you, then you should subclass Exception as described in the tutorial.
class MyError(Exception):
def __init__(self, message, animal):
self.message = message
self.animal = animal
def __str__(self):
return self.message

"What is the proper way to declare custom exceptions in modern Python?"
This is fine unless your exception is really a type of a more specific exception:
class MyException(Exception):
pass
Or better (maybe perfect), instead of pass give a docstring:
class MyException(Exception):
"""Raise for my specific kind of exception"""
Subclassing Exception Subclasses
From the docs
Exception
All built-in, non-system-exiting exceptions are derived from this class.
All user-defined exceptions should also be derived from this
class.
That means that if your exception is a type of a more specific exception, subclass that exception instead of the generic Exception (and the result will be that you still derive from Exception as the docs recommend). Also, you can at least provide a docstring (and not be forced to use the pass keyword):
class MyAppValueError(ValueError):
'''Raise when my specific value is wrong'''
Set attributes you create yourself with a custom __init__. Avoid passing a dict as a positional argument, future users of your code will thank you. If you use the deprecated message attribute, assigning it yourself will avoid a DeprecationWarning:
class MyAppValueError(ValueError):
'''Raise when a specific subset of values in context of app is wrong'''
def __init__(self, message, foo, *args):
self.message = message # without this you may get DeprecationWarning
# Special attribute you desire with your Error,
# perhaps the value that caused the error?:
self.foo = foo
# allow users initialize misc. arguments as any other builtin Error
super(MyAppValueError, self).__init__(message, foo, *args)
There's really no need to write your own __str__ or __repr__. The built-in ones are very nice, and your cooperative inheritance ensures that you use them.
Critique of the top answer
Maybe I missed the question, but why not:
class MyException(Exception):
pass
Again, the problem with the above is that in order to catch it, you'll either have to name it specifically (importing it if created elsewhere) or catch Exception, (but you're probably not prepared to handle all types of Exceptions, and you should only catch exceptions you are prepared to handle). Similar criticism to the below, but additionally that's not the way to initialize via super, and you'll get a DeprecationWarning if you access the message attribute:
Edit: to override something (or pass extra args), do this:
class ValidationError(Exception):
def __init__(self, message, errors):
# Call the base class constructor with the parameters it needs
super(ValidationError, self).__init__(message)
# Now for your custom code...
self.errors = errors
That way you could pass dict of error messages to the second param, and get to it later with e.errors
It also requires exactly two arguments to be passed in (aside from the self.) No more, no less. That's an interesting constraint that future users may not appreciate.
To be direct - it violates Liskov substitutability.
I'll demonstrate both errors:
>>> ValidationError('foo', 'bar', 'baz').message
Traceback (most recent call last):
File "<pyshell#10>", line 1, in <module>
ValidationError('foo', 'bar', 'baz').message
TypeError: __init__() takes exactly 3 arguments (4 given)
>>> ValidationError('foo', 'bar').message
__main__:1: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
'foo'
Compared to:
>>> MyAppValueError('foo', 'FOO', 'bar').message
'foo'

see how exceptions work by default if one vs more attributes are used (tracebacks omitted):
>>> raise Exception('bad thing happened')
Exception: bad thing happened
>>> raise Exception('bad thing happened', 'code is broken')
Exception: ('bad thing happened', 'code is broken')
so you might want to have a sort of "exception template", working as an exception itself, in a compatible way:
>>> nastyerr = NastyError('bad thing happened')
>>> raise nastyerr
NastyError: bad thing happened
>>> raise nastyerr()
NastyError: bad thing happened
>>> raise nastyerr('code is broken')
NastyError: ('bad thing happened', 'code is broken')
this can be done easily with this subclass
class ExceptionTemplate(Exception):
def __call__(self, *args):
return self.__class__(*(self.args + args))
# ...
class NastyError(ExceptionTemplate): pass
and if you don't like that default tuple-like representation, just add __str__ method to the ExceptionTemplate class, like:
# ...
def __str__(self):
return ': '.join(self.args)
and you'll have
>>> raise nastyerr('code is broken')
NastyError: bad thing happened: code is broken

As of Python 3.8 (2018, https://docs.python.org/dev/whatsnew/3.8.html), the recommended method is still:
class CustomExceptionName(Exception):
"""Exception raised when very uncommon things happen"""
pass
Please don't forget to document, why a custom exception is neccessary!
If you need to, this is the way to go for exceptions with more data:
class CustomExceptionName(Exception):
"""Still an exception raised when uncommon things happen"""
def __init__(self, message, payload=None):
self.message = message
self.payload = payload # you could add more args
def __str__(self):
return str(self.message) # __str__() obviously expects a string to be returned, so make sure not to send any other data types
and fetch them like:
try:
raise CustomExceptionName("Very bad mistake.", "Forgot upgrading from Python 1")
except CustomExceptionName as error:
print(str(error)) # Very bad mistake
print("Detail: {}".format(error.payload)) # Detail: Forgot upgrading from Python 1
payload=None is important to make it pickle-able. Before dumping it, you have to call error.__reduce__(). Loading will work as expected.
You maybe should investigate in finding a solution using pythons return statement if you need much data to be transferred to some outer structure. This seems to be clearer/more pythonic to me. Advanced exceptions are heavily used in Java, which can sometimes be annoying, when using a framework and having to catch all possible errors.

To define your own exceptions correctly, there are a few best practices that you should follow:
Define a base class inheriting from Exception. This will allow to easily catch any exceptions related to the project:
class MyProjectError(Exception):
"""A base class for MyProject exceptions."""
Organizing the exception classes in a separate module (e.g. exceptions.py) is generally a good idea.
To create a specific exception, subclass the base exception class.
class CustomError(MyProjectError):
"""A custom exception class for MyProject."""
You can subclass custom exception classes as well to create a hierarchy.
To add support for extra argument(s) to a custom exception, define an __init__() method with a variable number of arguments. Call the base class's __init__(), passing any positional arguments to it (remember that BaseException/Exception expect any number of positional arguments). Store extra keyword arguments to the instance, e.g.:
class CustomError(MyProjectError):
def __init__(self, *args, **kwargs):
super().__init__(*args)
self.custom_kwarg = kwargs.get('custom_kwargs')
Usage example:
try:
raise CustomError('Something bad happened', custom_kwarg='value')
except CustomError as exc:
print(f'Сaught CustomError exception with custom_kwarg={exc.custom_kwarg}')
This design adheres to the Liskov substitution principle, since you can replace an instance of a base exception class with an instance of a derived exception class. Also, it allows you to create an instance of a derived class with the same parameters as the parent.

You should override __repr__ or __unicode__ methods instead of using message, the args you provide when you construct the exception will be in the args attribute of the exception object.

See a very good article "The definitive guide to Python exceptions". The basic principles are:
Always inherit from (at least) Exception.
Always call BaseException.__init__ with only one argument.
When building a library, define a base class inheriting from Exception.
Provide details about the error.
Inherit from builtin exceptions types when it makes sense.
There is also information on organizing (in modules) and wrapping exceptions, I recommend to read the guide.

No, "message" is not forbidden. It's just deprecated. You application will work fine with using message. But you may want to get rid of the deprecation error, of course.
When you create custom Exception classes for your application, many of them do not subclass just from Exception, but from others, like ValueError or similar. Then you have to adapt to their usage of variables.
And if you have many exceptions in your application it's usually a good idea to have a common custom base class for all of them, so that users of your modules can do
try:
...
except NelsonsExceptions:
...
And in that case you can do __init__ and __str__ needed there, so you don't have to repeat it for every exception. But simply calling the message variable something else than message does the trick.
In any case, you only need __init__ or __str__ if you do something different from what Exception itself does. And because if the deprecation, you then need both, or you get an error. That's not a whole lot of extra code you need per class.

For maximum customisation, to define custom errors, you may want to define an intermediate class that inherits from Exception class as:
class BaseCustomException(Exception):
def __init__(self, msg):
self.msg = msg
def __repr__(self):
return self.msg
class MyCustomError(BaseCustomException):
"""raise my custom error"""

Try this Example
class InvalidInputError(Exception):
def __init__(self, msg):
self.msg = msg
def __str__(self):
return repr(self.msg)
inp = int(input("Enter a number between 1 to 10:"))
try:
if type(inp) != int or inp not in list(range(1,11)):
raise InvalidInputError
except InvalidInputError:
print("Invalid input entered")

A really simple approach:
class CustomError(Exception):
pass
raise CustomError("Hmm, seems like this was custom coded...")
Or, have the error raise without printing __main__ (may look cleaner and neater):
class CustomError(Exception):
__module__ = Exception.__module__
raise CustomError("Improved CustomError!")

I had issues with the above methods, as of Python 3.9.5.
However, I found that this works for me:
class MyException(Exception):
"""Port Exception"""
And then it could be used in code like:
try:
raise MyException('Message')
except MyException as err:
print (err)

I came across this thread. This is how I do custom exceptions. While the Fault class is slightly complex, it makes declaring custom expressive exceptions with variable arguments trivial.
FinalViolation, SingletonViolation are both sub classes of TypeError so will be caught code below.
try:
<do something>
except TypeError as ex:
<handler>
That's why Fault doesn't inherit from Exception. To allow derivative exceptions to inherit from the exception of their choice.
class Fault:
"""Generic Exception base class. Note not descendant of Exception
Inheriting exceptions override formats"""
formats = '' # to be overriden in descendant classes
def __init__(self, *args):
"""Just save args for __str__"""
self.args = args
def __str__(self):
"""Use formats declared in descendant classes, and saved args to build exception text"""
return self.formats.format(*self.args)
class TypeFault(Fault, TypeError):
"""Helper class mixing Fault and TypeError"""
class FinalViolation(TypeFault):
"""Custom exception raised if inheriting from 'final' class"""
formats = "type {} is not an acceptable base type. It cannot be inherited from."
class SingletonViolation(TypeFault):
"""Custom exception raised if instancing 'singleton' class a second time"""
formats = "type {} is a singleton. It can only be instanced once."
FinalViolation, SingletonViolation unfortunately only accept 1 argument.
But one could easily create a multi arg error e.g.
class VesselLoadingError(Fault, BufferError):
formats = "My {} is full of {}."
raise VesselLoadingError('hovercraft', 'eels')
__main__.VesselLoadingError: My hovercraft is full of eels.

For me it is just __init__ and variables but making sometimes testing.
My sample:
Error_codes = { 100: "Not enough parameters", 101: "Number of special characters more than limits", 102: "At least 18 alphanumeric characters and list of special chars !##$&*" }
class localbreak( Exception ) :
Message = ""
def __init__(self, Message):
self.Message = Message
return
def __str__(self):
print(self.Message)
return "False"
### When calling ...
raise localbreak(Error_codes[102])
Output:
Traceback (most recent call last): File "ASCII.py", line 150, in <module>
main(OldPassword, Newpassword) File "ASCII.py", line 39, in main
result = read_input("1", "2", Newpassword, "4")
File "ASCII.py", line 69, in read_input
raise localbreak(Error_codes[102]) At least 18 alphanumeric characters and list of special chars !##$&*
__main__.localbreak: False

Categories