Best practice for handling application logic error in a handler

[Chris]

What is the proper way for handling application-specific logic errors (i.e. the ones you'd expect to happen due to erroneous user input) in a handler?

For example, when user submits/posts a string that is supposed to match something in the db inside the post method of the handler, but it turns out nothing is matched. So you would return something to the user to signal that something is wrong.

Currently, I'm doing something like: self.finish('unmatched') for the above scenario, and use JavaScript on the client-side to parse the result (returned via an AJAX call to the handler) accordingly. However I feel there must be a more polished way for this.

[Lysander Trischler]

Hi Chris,

> What is the proper way for handling application-specific logic errors (i.e.
> the ones you'd expect to happen due to erroneous user input) in a handler?
>
> For example, when user submits/posts a string that is supposed to match
> something in the db inside the post method of the handler, but it turns out
> nothing is matched. So you would return something to the user to signal
> that something is wrong.

assuming it's an article ID the user requested or sth. similar HTTP 404 or 410
would be appropriate. But you said POST requests. It depends on your scenario
but when a user enters any sort of "bad" data (illegal values, numbers out of
range, too long or short strings, ...) and submits the form I always return a
HTTP 400 with an appropriate message telling what exactly was wrong. I wrote a
session engine which is also capable of storing messages over multiple
requests in the same session. In my base template all the messages are popped
out and displayed, so this will also work if a redirect must occour for some
reason and messages are only displayed once. Whenever I notice there are wrong
data coming in in my POST request I add the error message to the session, set
the 400 and render the form again with all submitted data prefilled in the
inputs (or at least the valid ones). Most HTTP client error codes don't fit my
actual problems, so 400 is my choice. Having such a simple setup is pretty
convenient in my opinion.

> Currently, I'm doing something like: self.finish('unmatched') for the above
> scenario, and use JavaScript on the client-side to parse the result
> (returned via an AJAX call to the handler) accordingly. However I feel
> there must be a more polished way for this.

So with this approach you're annoying users having JavaScript disabled. They
won't spot the actual problem with their submitted query.

Regards,
Lyse

[L-R]

You can override write_error in a different handler and then extend that handler to show the proper HTTP error code and grab/send the message from 'log_message'.

Have a look at http://www.tornadoweb.org/documentation/web.html#tornado.web.RequestHandler.write_error

[aliane abdelouahab]

if it is a database error, there is no acknowledgement, then you can
catch exception, DBMS drivers provide such errors handling.
if it is not a database error, then, i give a hack:
python is a script language.
tornado uses the class to bind it to a link.
so to satisfy an operation, the class must finish; starts from line 0
and gets line 10 (for example)
so the hack is to make a loop that only takes a signal from the latest
line, and put something in that line that triggers when it dont
receive an answer to loop from the latest line, catch this trigger and
customise this error message, normally it will exists, since i find
some websites give me errors (Stackoverflow.com for example) when my
message take lot of time to be sent.

[Chris]

Why do you overwrite in a different handler? How will this different handler be used when errors occur in other handler(s)?

[L-R]

You could also do it in the same handler, same result. It's just that if you have more than 1 handler, you'll be duplicating code. Also, this is just a slightly cleaner way of  returning error codes and messages in a standard format (especially if you have many handlers), but there might be something more suited to your specific form-submitting problem.

[Chris]

I see. So you meant all the other handlers (which may throw errors) subclass from this single handler that defines the uniform error handling. thanks.