Timeline for How can Arduino's 8 bit Microcontrollers handle C++
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 25, 2018 at 20:12 | comment | added | mbrig | @DmitryGrigoryev "errors for which you have no cure but to abort the current action, and possibly try again" are/should not be very common in embedded environments. Any possible "error condition" (external hardware not ready, transmitted failure, etc) should probably be explicitly handled and thus not really be exceptional. | |
| Jan 25, 2018 at 16:16 | comment | added | Graham | @DmitryGrigoryev Having to write unnecessary code is a bad thing, sure; but having to write more code to do the job properly is not. Handling errors appropriately really isn't unnecessary. Perhaps it takes more code if you're reliant on downstream functions to throw an exception if "new" fails and you try to dereference a null pointer, for example. But that's where PC coding and embedded coding differ. On a modern PC with essentially infinite resources you can generally get away with bad habits like that because it rarely if ever happens; but in the embedded world you can't. | |
| Jan 25, 2018 at 13:06 | comment | added | Dmitry Grigoryev |
@Graham Well yes, having to write extra code is a bad thing. Your argument reads a bit like "you shouldn't use default in a switch statement, because if you've done your design properly, there's not such thing as an unexpected value". Exceptions are not unexpected errors, they are errors for which you have no cure but to abort the current action, and possibly try again.
|
|
| Jan 25, 2018 at 12:46 | comment | added | Graham | @DmitryGrigoryev You say that like it's a bad thing. :) The second "initialisation" function could just report true/false, or it could be more detailed about the cause of failure. It's up to you as the coder. In general though, if you don't understand every error condition, then I'd say you haven't thought enough about your design or code. If you've done your design properly, there simply is no such thing as an unexpected error. Sure, there could be errors you think shouldn't happen, but a robust implementation will still cover them. | |
| Jan 25, 2018 at 12:01 | comment | added | Dmitry Grigoryev |
@Graham Possible, but it would mean all error conditions must be explicitly handled in code. You won't be able to simply write f(g(x)), you'll have to wrap every action which could fail in the error-handling code.
|
|
| Jan 25, 2018 at 11:15 | comment | added | Graham | @DmitryGrigoryev Or a third choice - use the constructor to set up the class in a known but non-working state, and have a second "initialisation" function which does all the operations which can fail. This is a fairly standard design pattern. If you then use a factory which is a "friend", the second "initialisation" function isn't exposed to the rest of the world, and the factory can legitimately report "I'm sorry, I can't do that, Hal". This has minimal extra cost compared to just calling a constructor; certainly nothing like as heavy as adding exception handling. | |
| Jan 25, 2018 at 8:46 | comment | added | Dmitry Grigoryev | @EdgarBonet It wouldn't be a very useful feature to support anyway, considering most boards have about 2K RAM. | |
| Jan 25, 2018 at 8:24 | comment | added | Edgar Bonet | AFAIK, the Arduino environment does not support exceptions. | |
| Jan 25, 2018 at 8:22 | history | answered | Dmitry Grigoryev | CC BY-SA 3.0 |