>
> PMFJI. I've been following this thread and have to agree with Sam.  
> When you call a method like save, you have the opportunity to examine  
> the results of the operation using a return code and handle any errors  
> locally. Exceptions, because they are often not handled locally, can  
> lack proper context for the cause of the problem. Exceptions are for  
> exceptional conditions, not predictable ones. Do you expect your C  
> runtime library to raise an exception when an fwrite fails? No, it  
> returns an error code and you handle it because, as a programmer, you  
> know that conditions like disk full or permission denied can happen.  
> Same in Ruby. Check return values. Punting this off to the ORM is,  
> IMO, an inferior option as compared to testing the success of a  
> critical operation.
>
> Just my (unasked-for) $.02

Just about any behavior can be defined as "expected," including power
loss, disk corruption, and memory failure.  Most of those COULD be
handled via return code.  It's a question of where you draw the line.

Merb defines and uses many exceptions.  Look at merb-core/lib/merb-
core/controller/exceptions.rb.  Then grep the code for those
exceptions.  I think you will find that you and Sam differ with the
Merb team on this.

Certainly "not found" on request is expected - there are lots of spam
bots, silly users, and bad web designers.  It happens all the time.
Merb uses exceptions to handle this case because it's the right tool
for the job.

Exceptions are used heavily in Merb.  Exceptions are not evil.  They
are a fantastic tool and frankly, invalid data is perfect place for
them.

Now were I writing a data validation engine, that is something that
really dealt with a lot of invalid records, then I agree invalid is an
expected state.  However in that case, I would not call save, I would
call valid?.


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to