On Nov 27, 11:24 am, Alex Neth <[EMAIL PROTECTED]> wrote: > An interesting option - I assume you mean returning a symbol. That > would unfortunately break any existing code and you would have to do > "if user.save == :success". It also would not succeed in bubbling up > error type that aren't handled.
Adam's referring to the throw/catch construct in Ruby. Which is actually much closer to what you want, but I believe you're required to catch your throws so it's not something we'll be adding to DM. > That is also again going back to C style return codes. Exceptions are > a language function designed for doing this... No, they're not. They're a *debugging* aid added to many modern languages. The are *not* meant to be used as GOTO statements. Unrolling the stack to prepare a stack-trace is extremely expensive. It's why you should not use exceptions for flow-control. Which is exactly what you're trying to do. You don't care about the stack-trace of a validation error. It's an extremely expensive operation and you're not interested in it at all. You only want to be jumped to a label. That's what throw/catch could help you with. Just pack in all your checks for various states of failure into your handler, and throw a general :model_error when #save returns false. Remember that Twitter hubbub back when DTrace became really popular? How they used the tool to find an exception that was being raised and caught internally in the framework? And how removing it (and presumably handling the same logic with the standard constructs intended for flow-control like if/case/while) improved performance significantly? Check this out: http://pastie.org/325462 Keep in mind a real framework is going to have a lot of overhead, but that's on top of your exception performance. So when you're pushing 200 requests per second, loosing half those on your contact_us action just because nobody ever manages to fill out all the fields correctly the first time is pretty painful. I was being generous in the pastie as well and assuming 3 out of 4 people got it right the first time. > , and they are used > throughout the Merb stack for similar situations. I would be genuinely surprised given Merb's focus on performance. Benchmark it: http://pastie.org/325477 ~50 times slower for exceptions on my machine. > I don't see why > they would be too heavy for validation errors in models. > > Exceptions in this case would have minimal impact and would make the > code cleaner and more correct. How is it more correct? Write a helper to handle exceptions if you want. More correct for an end-user isn't displaying global 404's or 500's that's aren't context or content (model) specific. > I haven't looked much into ruby exception benchmarks. It would be > unfortunate if people resort to not actually using ruby as it was > designed because of such a performance issue. Using Exceptions as glorified GOTOs was popularized by some examples in Rails. I seriously doubt Matz ever intended simple cases that could be handled by an if() should be handled by global exception handlers. You might make that claim in Python since they explicitly state that "it's better to ask forgiveness than permission", but Ruby is not Python. > Perhaps someone can refer me to an article representing the general > "anti-exception" argument Sam seems to subscribe to. http://tinyurl.com/6dmga4 ;-) (I couldn't resist, sue me!) No really, I had to learn this the hard way myself. But trust me, you're trying to force a square peg through a round hole here. Sorry if I'm being a bit harsh. I just tired of having this discussion. Compensate me for my time and I'll talk your ear off. ;-) -Sam --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
