On Saturday 31 July 2010 20:15:58 Jason Spencer wrote: > == Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article > [...snip] > > Just a thought. > Jason
I honestly don't think that exception handling is a particularly expensive solution in most cases. When dealing with an error, it's likely to either be related to I/O (be it an actual I/O error or input from a user or file) or a logic error in the code. For logic errors, efficiency isn't really an issue, since they shouldn't be happening. If they are, go fix your code and it won't be an issue. For I/O-related errors, I/O is already slow. You can't expect that to be efficient anyway. And if you're get an I/O error, you have a problem that has to be dealt with, and efficiency probably isn't an issue at that point anyway. The main issue with exceptions is whether code handles them correctly, and that's just as true of error codes. Particularly when you add RAII and scope into the mix, it's really not all that bad. There's always the issue over checked exceptions with there being pros and cons both ways, but overall, I'm definitely pro-exceptions and anti-error handling. I really do think that it makes for better code and that efficiency really isn't an issue in most cases. Maybe if you're dealing with embedded code, it might matter. But beyond something like that, exceptions will be better. As for how to use exceptions, I really think that Java does it quite well and is a good role model overall. It's just the checked exceptions that are particularly debatable. Your suggestion isn't necessarily bad, but I really don't think that there's anything wrong with using exceptions and that having to deal with errors explicitly like you would with error codes or your suggestion just clutters code and makes it less maintainable. - Jonathan M Davis