IMHO (though I am not sure at all) it should perform the check internally and redirect, otherwise it's a waste of time in this way: http://e-haitham.blogspot.com/2008/06/rails-exception-handling-has-never-been.html
On Jul 11, 11:19 pm, mdipierro <[email protected]> wrote: > 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 <[email protected]> wrote: > > > > > On Sat, Jul 11, 2009 at 2:11 PM, rb <[email protected]> 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 <[email protected]> wrote: > > > > Probably RecordNotFound exception or just an attribute like > > > > crud.setting.record_not_found? > > > > > On Jul 11, 7:01 pm, mdipierro <[email protected]> wrote: > > > > > > You are right. we need to deal with that exception somehow. What do > > > > > you propose? > > > > > > massimo > > > > > > On Jul 11, 10:13 am, Vidul <[email protected]> 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 <[email protected]> wrote: > > > > > > > > What kind of exceptions? > > > > > > > > On Jul 11, 7:04 am, Vidul <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
