I am speaking from a non-technical user-perpective (user but not a developper of Nim) so dont be too harsh on me.
When i think about it, the exception raising is an invasive process into the calling program. Future computing maybe should be more polite in terms of respons-request style. (I have also philosophised about communication between components that is programming-language-independent, but that's another story). Error-codes fit in that request-respons strategy. However an additonal info-field for extra information could be useful. Exception-handling is kind of useful in the premature phase of a program, when not yet all test-cases and outcomes have been thought of / tested. Than you repair the code and exceptions no longer occur. However there may be always fringe-cases where for example a component is not installed. I am not very versed in the technicals of the error-code world; is the error-code a return-value from the function or is it a separate mechanism like exceptions? And if it is a return-value, is there still room for additonal info? Now it's the time to request features and i have another one; built-in location-information; where exactly did the error occur? So error-codes ok but: * option of giving extra free info. * if possible and not too expensive: schematic location-info (as a programmer i want to know as much as possible about an error in a schematic representation as opposed to a long string, but that may come with a price..)
