The issue is the SQLFORM and crud examples in the books and everywhere
look like
def index():
return dict(form=crud.update(...))
and we do not want to change them all into
def index():
try:
form=crud.update(...)
except somenewexcetpion:
dosomething
return dict(form=form)
Same applies to SQLFORM. This is a rare condition since all the update
forms are linked from other pages. I think it is ok to return an HTTP
(404) and if the user wishes to do so, the user can check explicitly:
def index()
record=db.table[request.args(0) or 0]
if not record: do something
return dict(form=crud.form(db.table,record))
To me the only issue is whether crud update should perform this check
internally and redirect to a standard default url.
Massimo
On Jul 11, 2:37 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> On Sat, Jul 11, 2009 at 2:11 PM, rb <rbspg...@gmail.com> wrote:
>
> > Isn't it true that the choice between using a return error code and
> > using the exception mechanism is decided by whether the result is
> > expected or not?
>
> Well, "exceptional condition" means out of the ordinary - you have no
> doubt used try/except on file opens, db connections, etc.
>
> The motivations I have seen most often for what you quote above is the
> "weightiness" of exception mechanisms, that is to say return codes are
> preferred when exceptions mean a performance hit.
>
> But exceptions have the distinct benefit of de-coupling.
>
> If _I_ raise an exception, what I say is "someone violated my contract: I
> have preconditions I expect to operate in" --- raising an exception doesn't
> care who caused it, or who should handle it - handling is left to the
> responsibilty of the callee...
>
> SO that is the benefit of exceptions.
>
> Wondering what the exception structure overhead is in Python (because of
> your post), I looked a little, and found this:
>
> http://blog.hackers-cafe.net/2009/02/python-to-raise-exception-doesnt...
>
> So it seems exception overhead in Python is non-existent....
>
> which leaves the choice to merely the best choice structurally (performance
> doesn't need to be a consideration).
>
> Regards,
>
> - Yarko
>
> > If record_not_found is a common, reasonably expected
> > outcome then maybe it is better to use a return code to signal this so
> > that the logic to deal with it is inline with the algorithm of the
> > function. If a record exists but the read fails that might always be
> > an exception case, but trying to read a record and not knowing first
> > whether it exists may be better handled by the inline control logic.
>
> > That is, don't most other systems use a return code to single
> > not_in_table rather than using exception facility?
>
> > Isn't it best to reserve use of the exception mechanism for errors
> > that should _rarely_ happen and needn't be covered by the inline
> > logic?
>
> > --
>
> > On Jul 11, 9:06 am, Vidul <vidul.pet...@gmail.com> wrote:
> > > Probably RecordNotFound exception or just an attribute like
> > > crud.setting.record_not_found?
>
> > > On Jul 11, 7:01 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > You are right. we need to deal with that exception somehow. What do
> > > > you propose?
>
> > > > massimo
>
> > > > On Jul 11, 10:13 am, Vidul <vidul.pet...@gmail.com> wrote:
>
> > > > > For example:
>
> > > > > def update_comment():
> > > > > form=crud.update(db.comment, request.args(0))
> > > > > retur dict(form=form)
>
> > > > > where args(0) does not exist in the database.
>
> > > > > On Jul 11, 5:51 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > > > > What kind of exceptions?
>
> > > > > > On Jul 11, 7:04 am, Vidul <vidul.pet...@gmail.com> wrote:
>
> > > > > > > Hi,
>
> > > > > > > Auth and CRUD are amazing, no doubt, but is there a best practice
> > for
> > > > > > > the exception handler / ing of read / create / update / delete
> > > > > > > actions?
>
> > > > > > > Thank you!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
