On Nov 26, 4:18 pm, Sam Smoot <ssm...@gmail.com
> The benchmark is flawed. It doesn't actually raise errors. I commented
> on the original blog with a working example. The exception raising
> code is well over 100 times slower.
Fair enough. On the other hand, the additional performance cost you
noticed is only an issue if something does not work as advertised and
you need to raise an exception. If a saving a model fails you are
likely to be in a situation where performance is the least of your
worries. And you can remove a conditional from the happy path by
using exceptions (since we are talking about microsecond level
I suspect the overhead of an exception raise would be way down in the
noise of handling any real HTTP request. To be fair, though, it
would, as you pointed out, really need to be tested in-situ to be
sure one way or the other.
> Exceptions should be reserved for exceptional situations, and these
> aren't. I agree we should have versions that do raise errors, but the
> defaults should simply return statuses IMO.
Of course exceptions should only be raise for "exceptions
situations". I, however, consider being unable to insert/update a
record in the database a exceptional situation. After it almost
always works. I suppose there might be a few situations where the
application might consider that unexceptional but the library does not
have the context to determine when that is exactly.
> Sorry to pull rank. I don't like to do that. I'll happily accept any
> patches you'd like to submit regarding error-raising variants. But I
> feel pretty strongly about this one.
If you are going to pull rank then, perhaps, the discussion is over.
> If you really want to use some alternative form of flow-control, maybe
> we could look into continuations? The same ability to "inject" code
> when a certain state occurs, but without the performance penalty (at
> least that's my assumption).
IIRC, continuations are not included Ruby 2.0 so I would not really
want to get into using a mechanism with such short life span. It is
an interesting idea, though.
> I'd also be happy to accept a Errorful plugin/patch that overwrites
> the default methods with their error-raising brethren. So you can
> still eat your cake if you're willing to require 'plugins/
> error_happy'. That seems like a decent compromise?
Not really. If you decide to continue to return status codes I would
probably just resort to the `*!` versions (assuming such variants
exist). There is a lot to be said for not confusing matters which is
primarily what overwriting methods as you propose would achieve, I