Description

I believe that this is actually a quite important exception to have available considering the device that MicroPython is typically being installed on has a very high probability of being used with some form of IO.

These are the exceptions that would be the most benificial to add. Having not only the `` but possibly the ones listed below as well.

• ConnectionError: subclass of OSError, see below, parent class of 3 exceptions
• ConnectionResetError: subclass of ConnectionError, obvious uses
• ConnectionRefusedError: subclass of ConnectionError, obvious uses
• ConnectionAbortedError: subclass of ConnectionError, obvious uses
• BlockingIOError: subclass of OSError, used if IO is busy
• InterruptedError: subclass of OSError, used if there is an issue inside of an interrupt???
• TimeoutError: subclass of OSError, obvious uses.

Now I do understand that these exceptions are subclasses of OSError and they are not hard to add in Python code at runtime but doing that does come at a cost. There is going to be more memory and flash used that if it was implemented in C code. They would also not be available to use in C code either, say a user module or in one of the built in modules.

as an example.

If using I2C when trying to send to a device that is no longer attached to the bus what happens? An OSError gets raised. But what is the OSError for? The error is easily identified if it gets output to stdout, et al. but to identify what the error is programmatically requires more work to be done. If that additional work needs to be done to identify the exception that has occurred in order to determine what the program needs to do next could be an expensive thing if it happens many many times. The exception is always going to get raised no matter what. being able to narrow down what the cause is for something like a connection issue should be able to be done simply by the actual exception that gets raised without any additional work needing to be done.

Code Size

I do not believe that adding the additional exceptions would increase the code size by very much. maybe tens of bytes possibly? Or a couple hundred bytes? I would be taking a guess as I really do not know how much it would impact the code size. However, I do believe when you looks at things as a whole user code and all and not just the MicroPython code it has the potential to save a whole lot more than the cost. It can save program size, memory use and also processor use. That additional user code to break down an exception to identify the actual issue is expensive to do because it is being done in python code. It's less expensive to break down an exception in C code to make it easier to identify in python code. Seeing as how the devices rely heavily on IO to communicate whether it be over WiFi, SPI, I2C or some other communications type this specific breaking down of the exception in C code is almost a must due to the use of it being very broad.

I can see where they have been added but are not commented out. This is done in py/objexcept.c. making them active again looks to be fairly easy to do. The trick is to go through all of the ports and extension modules at the same time that is done and make the modifications to use the newly added exceptions. This would need to be done at the same time the exceptions are added back in. It would not break the API at all because these exceptions are all subclasses of OSError so if a users code currently parses an OSError exception that gets raised it would continue to function like it does currently.

The devices being so heavily IO driven is what really makes it worth having these additional exceptions added. The key to their usefulness is them being used in the various IO drivers at the C level.

Implementation

I hope the MicroPython maintainers or community will implement this feature

Code of Conduct

Yes, I agree