When to use raise NotImplementedError

Question

Is it to remind yourself and your team to implement the class correctly  I don t fully get the use of an abstract class like this   class RectangularRoom object       def   init   self  width  height           raise NotImplementedError      def cleanTileAtPosition self  pos           raise NotImplementedError      def isTileCleaned self  m  n           raise NotImplementedError

User · Answer

You might want to you use the  property decorator    gt  gt  gt  class Foo             property         def todo self                   raise NotImplementedError  To be implemented         gt  gt  gt  f   Foo    gt  gt  gt  f todo Traceback  most recent call last     File   lt stdin gt    line 1  in  lt module gt    File   lt stdin gt    line 4  in todo NotImplementedError  To be implemented

User · Answer

As the documentation states  docs        In user defined base classes  abstract methods should raise this exception when they require derived classes to override the method  or while the class is being developed to indicate that the real implementation still needs to be added    Note that although the main stated use case this error is the indication of abstract methods that should be implemented on inherited classes  you can use it anyhow you d like  like for indication of a TODO marker

User · Answer

Consider if instead it was   class RectangularRoom object       def   init   self  width  height           pass      def cleanTileAtPosition self  pos           pass      def isTileCleaned self  m  n           pass   and you subclass and forget to tell it how to isTileCleaned   or  perhaps more likely  typo it as isTileCLeaned    Then in your code  you ll get a None when you call it     Will you get the overridden function you wanted  Definitely not  Is None valid output  Who knows    Is that intended behavior  Almost certainly not   Will you get an error  It depends    raise NotImplmentedError forces you to implement it  as it will throw an exception when you try to run it until you do so  This removes a lot of silent errors  It s similar to why a bare except is almost never a good idea  because people make mistakes and this makes sure they aren t swept under the rug   Note  Using an abstract base class  as other answers have mentioned  is better still  as then the errors are frontloaded and the program won t run until you implement them  with NotImplementedError  it will only throw an exception if actually called

User · Answer

As Uriel says  it is meant for a method in an abstract class that should be implemented in child class  but can be used to indicate a TODO as well  There is an alternative for the first use case  Abstract Base Classes  Those help creating abstract classes  Here s a Python 3 example  class C abc ABC        abc abstractmethod     def my abstract method self                     When instantiating C  you ll get an error because my abstract method is abstract  You need to implement it in a child class  TypeError  Can t instantiate abstract class C with abstract methods my abstract method  Subclass C and implement my abstract method  class D C       def my abstract method self                     Now you can instantiate D  C my abstract method does not have to be empty  It can be called from D using super    An advantage of this over NotImplementedError is that you get an explicit Exception at instantiation time  not at method call time

User · Answer

One could also do a raise NotImplementedError   inside the child method of an   abstractmethod-decorated base class method   Imagine writing a control script for a family of measurement modules  physical devices   The functionality of each module is narrowly-defined  implementing just one dedicated function  one could be an array of relays  another a multi-channel DAC or ADC  another an ammeter etc  Much of the low-level commands in use would be shared between the modules for example to read their ID numbers or to send a command to them  Let s see what we have at this point  Base Class from abc import ABC  abstractmethod    lt  we ll make use of these later  class Generic ABC           Base class for all measurement modules             Shared functions     def   init   self             do what you must         def  read ID self             same for all the modules      def  send command self  value             same for all the modules   Shared Verbs We then realise that much of the module-specific command verbs and  therefore  the logic of their interfaces is also shared  Here are 3 different verbs whose meaning would be self-explanatory considering a number of target modules   get channel   relay  get the on off status of the relay on channel  DAC  get the output voltage on channel  ADC  get the input voltage on channel  enable channel   relay  enable the use of the relay on channel  DAC  enable the use of the output channel on channel  ADC  enable the use of the input channel on channel  set channel   relay  set the relay on channel on off  DAC  set the output voltage on channel  ADC  hmm    nothing logical comes to mind     Shared Verbs Become Enforced Verbs I d argue that there is a strong case for the above verbs to be shared across the modules as we saw that their meaning is evident for each one of them  I d continue writing my base class Generic like so  class Generic ABC         continued           abstractmethod     def get self  channel           pass       abstractmethod     def enable self  channel           pass       abstractmethod     def set self  channel           pass   Subclasses We now know that our subclasses will all have to define these methods  Let s see what it could look like for the ADC module  class ADC Generic        def   init   self           super     init        lt  applies to all modules           more init code specific to the ADC module          def get self  channel             returns the input voltage measured on the given  channel       def enable self  channel             enables accessing the given  channel   You may now be wondering   But this won t work for the ADC module as set makes no sense there as we ve just seen this above   You re right  not implementing set is not an option as Python would then fire the error below when you tried to instantiate your ADC object  TypeError  Can t instantiate abstract class  ADC  with abstract methods  set   So you must implement something  because we made set an enforced verb  aka   abstractmethod    which is shared by two other modules but  at the same time  you must also not implement anything as set does not make sense for this particular module  NotImplementedError to the Rescue By completing the ADC class like this  class ADC Generic        continued      def set self  channel           raise NotImplementedError  quot Can t use  set  on an ADC  quot    You are doing three very good things at once   You are protecting a user from erroneously issuing a command   set   that is not  and shouldn t   be implemented for this module  You are telling them explicitly what the problem is  see TemporalWolf s link about  Bare exceptions  for why this is important  You are protecting the implementation of all the other modules for which the enforced verbs do make sense  I e  you ensure that those modules for which these verbs do make sense will implement these methods and that they will do so using exactly these verbs and not some other ad-hoc names

[python] When to use 'raise NotImplementedError'?

Examples related to python

Examples related to oop