I do not know how one would ever detect IO errors besides from the OS.
Seems the Python devs thought this, too. ;-) Python merged IOError and OSError a while ago:
https://docs.python.org/3/whatsnew/3.3.html#pep-3151-reworking-the-os-and-io-exception-hierarchy
I also like the idea of subclasses for different error conditions, to avoid explicit errno checking. I don't know if there would be a reason not to do this in Nim.
So yeah write this one line of code that "feels as low level as C". Pure hyperbole.
This might be another thing that fell through the cracks when @Araq did his pre-1.0 stdlib quality control scan.
Hardly, you can do IO without an OS.
osLastError doesn't necessarily correspond to the OSError exception in question.
try:
try:
foo()
except:
myLogFunction("error happened")
raise
except OSError:
echo osLoastError()
@yglukhov - OSError already has errorCode. I think you maybe meant literally any other exception type in your last except and maybe by "error class" you mean Exception or CatchableError?
Anyway, you do have the option of saving a copy of osLastError() in a variable (declared before the first try) at the re-raise site. I agree that is not the prettiest thing ever, but "impossible" seems strong.
Child types of IOError is cleanest. There probably aren't even so many IOError raise sites. OTOH, there could be "coverage" problems with some OSes having weird errnos for open, for example. open tends to have nearly the most possible errors in my experience. So, both some common sub-types and the errorCode is probably the best idea here.
There was also this recent vaguely related issue showing a non-exception way to do open.
@satoru - None of this is a reason to not use Nim. You can always write your own file APIs that raise OSError for any file-oriented system call errors (or do your own exception type hierarchy for such). It is always hard to decide project priorities, though. It is often best to think of Nim's stdlib as "something to get you started" not "a final/best answer".
For what it's worth, I think this kind of stdlib change would impact and/or interest enough people that you/someone could write an RFC to get more feedback.
@cblake, thanks for the correction, I actually meant IOError. I suggest saving a copy is impossible because (a) that's usually not your code that doesn't do that and (b) you can't make everyone to always account for a possibility of IOError going through their catch blocks. If that makes sense?
I agree it's almost not an issue most of the time, just let's not pretend there's nothing to improve here @Araq ;)