Mind that we do what rails but in a different ways. Our exceptions
generate tickets and tickets can be trapped with routes_on_error. If
you want a custom error handler you can define it using a decorator:
def onerror(g):
def _onerror(f):
try: return f()
except HTTP,e: raise e
except: Exception, e: g(e)
return _onerror
def myerrorhandler(error):
return 'oop! %s' % error
@onerror(myerrorhandler)
def index(): return 1/0
Here we are dealing with one specific case: update a record that does
not exist. This, version in trunk, DOES NOT generates an exception
just HTTP 404 Object Not Found.
Massimo
On Jul 12, 8:43 am, Vidul <[email protected]> wrote:
> 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-ne...
>
> 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
-~----------~----~----~----~------~----~------~--~---
