On Tuesday, July 20, 2010 02:50:14 pm Jordan Ritter wrote:
IME, the meanings of safe vs. bang methods and what class of errors do
exceptions represent have always been, at their core, a conscious
philosophical difference between DM and AR.
If it were possible to support both philosophies,
On Tuesday, July 20, 2010 02:01:14 pm Jared Morgan wrote:
I'm confused. I was under the impression that the only case in which
save would not raise on error on failure is when validation fails
Digging around in the code a bit, this seems to be true.
In this case, it's not the code that's
the
On Tuesday, July 20, 2010 09:07:44 am Paul Barry wrote:
How about adopting the ActiveRecord convention of save that returns a
boolean and save! that raises an exception?
save! already has a meaning in DM -- save without validation. So it's the even
more dangerous version.
--
You received
How about adopting the ActiveRecord convention of save that returns a
boolean and save! that raises an exception?
On Mon, Jul 19, 2010 at 11:46 PM, David Masover ni...@slaphack.com wrote:
On Sunday, July 18, 2010 11:59:41 am Martin Gamsjaeger wrote:
I think the motivation behind DM not
IME, the meanings of safe vs. bang methods and what class of errors do
exceptions represent have always been, at their core, a conscious
philosophical difference between DM and AR.
One (much older) school of thought: exceptions are exceptional behaviour --
they typically represent
Very interesting point. So in the end you are recommending to raise only in
order to prevent further damage right?
In my current project there are quite a lot .saves and failing saves can
lead there in a lot of cases to unpredictable/unwanted behaviour. (And also
did in the recent time...) But
On Sunday, July 18, 2010 11:59:41 am Martin Gamsjaeger wrote:
I think the motivation behind DM not raising an exception on any save
failure by default is a very simple and intuitive one.
DM cannot assume to know exactly when a failing save can really be
considered *exceptional* behavior.
Nice... Actually the default behaviour (not raising even though .save
failed) also made me think dm is broken. Anyways: It would be nice to
mention which class is thrown, i.e. SaveFailureError right? And that it has
an attribute @resource...
Regards, Philip
2010/7/17 Martin Gamsjaeger
I think the motivation behind DM not raising an exception on any save
failure by default is a very simple and intuitive one.
DM cannot assume to know exactly when a failing save can really be
considered *exceptional* behavior. Rather than forcing the user to
treat every single save failure as an
I see. Well I guess it depends very much on the project. In a rather complex
project I think exceptions should be preferred to prevent weird behaviour.
But in very small projects it might be more overhead than usage...
Still in my opinion a failing operation is exceptional but this is more of a
It probably is :) In any case, I updated the docs to mention the error
raised when #raise_on_save_failure is in effect and a save operation
failed:
http://datamapper.org/docs/create_and_destroy
Martin
On Sun, Jul 18, 2010 at 19:12, Philip Silva psilva...@googlemail.com wrote:
I see. Well I
It would be nice if this feature was on the main documentation of
datamapper. It is kinda sad that the easiest way to find is through a
post (with very high google rank) called 'DataMapper is inherently
broken' (http://www.drmaciver.com/2010/04/datamapper-is-inherently-
broken/). It is worse that
Daniel,
You are absolutely right, that doesn't make the best impression :/ I
added information about #raise_on_save_failure to the doc site.
http://datamapper.org/docs/create_and_destroy
Thx for the tip! If you know of any other particular areas you'd like
to see the docs improved, feel free to
13 matches
Mail list logo
