I'm starting to be persuaded... However,
1) Don't think there is no performance penalty. There is.
2) Java is slow. Everything is relative and when you are using an
interpreted language Java looks fast. Solution: Make faster hardware.
What begins to sway me to the exceptions point of view is the concept
that we should optimize for the programmer and not the computer. I'm
still not sold on exceptions being in the ORM and particularly not
inconsistently as in ActiveRecord (some things return object/nil,
others raise exceptions).
Finally, there are benchmarks to support any point of view, and FWIW
here's another one. Of course the code is trivial and the expense of
the method invocation and the exception handling are all that are
measured here. Clearly, this is a fiction never duplicated in real
code. It does, however, allow you to understand that the cost of
raising an exception is over 8x the cost of returning a value (on my
MBP).
require 'benchmark'
class BozoException < Exception; end
class TestException
def something_risky_with_exception
raise BozoException.new("Bozo raised an exception")
end
def something_risky_without_exception
return BozoException.new("Bozo raised an exception")
end
end
n = 10_000
test = TestException.new
Benchmark.bm do |x|
x.report('using exceptions: '){ n.times{
begin
test.something_risky_with_exception
rescue BozoException => ex
ex
end
}}
x.report('not using exceptions:')
{ n.times{ test.something_risky_without_exception }}
end
user system total real
using exceptions: 0.160000 0.020000 0.180000 ( 0.182851)
not using exceptions: 0.030000 0.000000 0.030000 ( 0.023572)
On Dec 2, 2008, at 1:43 PM, Vivek Sharma wrote:
>
> Folks, I think I'm going to have to side with Alex on this one. Let's
> clearly state the problem:
>
> "Sending a return code back rather than an exception causes a certain
> amount of opaqueness in the code. It's becomes impossible to know the
> real details of an error."
>
> IMHO, I also think that adding all of these validation checks around
> the error is very un-DRY. It makes a lot of sense for me to have the
> ORM handle this.
>
> I think the argument against exceptions finally comes down to this:
>
> "We will take a huge performance hit for using validation exceptions.
> Therefore we won't do it."
>
> A couple comments:
>
> 1.) Java ORMs make use of exceptions all the time and no one would
> accuse Java of being slow.
> 2.) I thought the goal of an ORM was to optimize for developer time
> and to help them stay DRY.
>
> It seems to me that if there really are huge performance issues with
> Ruby's exception handling then that's where the energy should be
> dedicated and it should be fixable (as shown by Java).
>
> -- Vivek
>
> On Dec 2, 3:53 am, Alex Neth <[EMAIL PROTECTED]> wrote:
>>> I think we need to agree to disagree on this one. I'm not as up to
>>> speed on Ruby's exception structure as C-like languages, but it
>>> stands
>>> to reason that there would be similarities. Every time an exception
>>> context is established, a set of unwindable frames need to be
>>> created
>>> so your program can basically perform a non-local jump outside its
>>> current execution context while at the same time cleaning up objects
>>> left lying around unfinished all the way up the call stack until the
>>> exception is finally handled. Garbage collection simplifies this
>>> immensely, but doesn't make the overhead go away completely. You
>>> are,
>>> therefore, suggesting an implementation decision at the ORM level
>>> that
>>> is more memory-intensive and cpu-intensive strategy than simply
>>> returning values.
>>
>>> In many ways, merb *is* a good model because they have tried to make
>>> implementation decisions (down to what ORM if any should be used)
>>> that
>>> could sensibly be decoupled from the framework easy to decouple.
>>> That
>>> might be a good way to look at error propagation strategies. I think
>>> DataMapper is currently at a point where it is not tied to Ruby's
>>> exception handling. If that's part of your implementation strategy,
>>> wrappingsave! (as was previously suggested) is one option. You could
>>> also fork the project and implementsavein your preferred style.
>>> You'd probably get most of the goodness of the project in merges.
>>> And,
>>> you might be right.Exceptionsmight be superior in all ways to simple
>>> error returns. That's what's great about Open Source: You can have
>>> it
>>> your way and if your was is a better one, people will recognize
>>> that.
>>
>> As far as the mechanism ofexceptionsbeing expensive, I'm not sure
>> that's inherently so, although that implementation level of the
>> language is not an area I'm an expert in.
>>
>> There is no reason for it to actually assemble a string backtrace
>> though until backtrace is called. It seems would only need to store
>> some sort of stack reference. I'm not speaking from a compiler
>> background though.
>>
>> I am quite convinced that in this case of DM,exceptionsare
>> superior. I'm not sure at this point it justifies me maintaining a
>> fork. I was hoping to get my position out there. Perhaps it will
>> come
>> up again.
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
