| |||||||||||||
Making EPERM friendlierMaking EPERM friendlierPosted Jan 20, 2013 9:40 UTC (Sun) by alankila (subscriber, #47141)In reply to: Making EPERM friendlier by wahern Parent article: Making EPERM friendlier
I know this take on the issue isn't going to be popular here, but I like exceptions as error-reporting system. It is imho hell of a lot better than single integer. The information contained in the stack trace allows me to infer the state of the system and generally determine the point of failure, or the offending piece of code I wrote.
If only C, or the userspace-kernel API could have something like that...
(Log in to post comments)
Making EPERM friendlier Posted Jan 21, 2013 8:40 UTC (Mon) by epa (subscriber, #39769) [Link]
An exception is essentially an alternative return value from the function. (The *implementation* of exception handling in languages such as C++ is something quite different, but that is not relevant here). I agree that it is great to have a structured object giving details on the error. However that may be a little ambitious - and in 20 years we might be having arguments about how the error details don't fit into the C structure defined way back in 2013. I suggest that a string, such as Plan 9's errstr, is a reasonable compromise between a single int (clearly inadequate) and a complex structured exception object (too complex to be widely adopted at the kernel level).
|
|||||||||||||