Regarding the benchmarking done here, we've seen 8x to 50x cost for
exceptions. The benchmarks are nonsensical at best. What is it 50
times of? If you do something extremely quick (like multiply 8*5) and
test it with and without an exception - it will be a very high X
factor, like 50. If you do something that takes longer (like create
an object) it will be a much lower X factor. If you do something that
takes a reasonable amount of time, like validate a record, the X
factor will be negligeable as show by psadauskas's benchmark. The
other benchmarks are meaningless. It's the absolute time that
matters!
Sam's benchmark is particularly meaningless. In fact it shows that an
exception can be thrown in 0.00002 seconds. That's 2/10 of a
millisecond. s.ross's benchmark shows 1/10 of a millisecond. Are you
seriously going to worry about that? What percentage of the entire
save method do you think that is?
Based on s.ross's test, it's about the time it takes to create 4 empty
objects. That's is not much cost in my book. Probably similar to
appending a few strings.
I think this aversion to exceptions comes from the .net world, where
I've heard exceptions are quite the bear.
As for the other arguments, I agree we've gone through most of the
points here, but it's been an interesting debate and has certainly
made me think, although I haven't changed my mind. I have never been
a fan of certain similar things that are commonplace, such as
returning from the middle of a method. I generally agree that all
code paths should go to the end of the method when possible, and
exception code should be handled carefully.
I'm also not a fan at all of "unchecked" exceptions, except for
serious errors that would result in a system crash, such as a
dereferencing a null pointer. Java allows you to write checked
exceptions, which means that the caller MUST handle the exception, or
declare that the exception is thrown and pass it through. The latter
is often a bad practice, as it can introduce many of the issues Sam
worries about. All my Java exceptions are checked. Unfortunately,
Ruby has no such feature, but good documentation should take care of
that to some extent.
try {
object.save();
} catch(ObjectInvalid) {
...
}
Object.save() throws ObjectInvalid, DatabaseError {
if(self.valid()) {
try {
storeData(); // throws DatabaseError
// any code here must make sure it need not (and probably should
not) be executed if storeData() fails
} finally {
// Write anything here that must happen
}
} else {
raise new ObjectInvalid(self.errors();
}
// No code should be here - it should be after the storeData() call
or in the finally block.
}
That is about as safe as you can be from a "flow control"
perspective. It's possible to write unsafe code with and without
exceptions. Exceptions just make certain things easier. There isn't
much difference between them. If you are using return values, you are
just using convoluted if/then statements to exclude the code the
exception would skip over. If written well that skipped code is what
you explicitly don't want to execute when the failure occurs,
otherwise you would have put it in an ensure/finally block.
I actually sat down and thought about how to design a language with
error handling as a separate path from returns, but without using
exceptions. I thought I was successful, until I realized I had just
reinvented the functional equivalent exceptions, although my language
does force you to write safer exceptions where the code path is clear
(i.e. it does not allow code where I say there shouldn't be above.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---
