I don't think there's a "true ruby" way of disabling the backtrace though I have seen a gem which attempts to hide the backtrace in log output for rails applications.
This ofcourse would not be an option for DM because a) it adds a unneeded dependency to DM and b) would still cause ruby to inspect the stack (which is the actual performance hit). If you don't want the stacktrace to be inspected, using throw/catch would be the best way to go. Also, I should point out that many of the core DM contributors value functional well-organized easy-to-maintain code over 'pretty' code. This value statement likely needs better verbalizing than that but it's the main reason why you're not likely to see helper methods scattered about DM and instead see canonical ruby idioms (or faster alternatives when available). The closer the API gets to 'plain ol ruby', the faster new users will be able to pick up DM and the less overall API 'inertia' has to be overcome while DM grows. That being said, I personally wash my hands of this discussion and defer all decisions to those smarter than I. === Adam French On Thu, Dec 4, 2008 at 11:46 AM, Eltiare <[EMAIL PROTECTED]> wrote: > > Is there any way to disable the backtrace? If it's an expected error, > there should be no need for a backtrace. One of the nice things about > raising an error is that it also rolls back transactions. It really is > too bad that it's such a performance hit as rescuing errors makes the > code so much nicer and readable, IMO. Throw/catch is not a > replacement for this way of doing things as it does not roll back > transactions (you'd have to checks after the block). This might > actually be desirable in the eyes of the DM team, though - as perhaps > some people don't _want_ a transaction rolled back if there's a > validation error. Plus it seems like you are still doing if/then/else > checks if you want to do something differently depending on if there's > a validation error or not. I'm kinda in the middle on this one. It > seems to me that GOTO-like statements in this case are not evil > because they are not global GOTO's - making them much more > maintainable than the nasty statements of yester-years. Bah, I hate > it when I have to choose between writing pretty code and writing for > performance (which seems to be all the time....) > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
