Is there any good use cases for the after_request in Flask? Some people seem to use it to close a database connection but it seems to be an error since it won't be called if there is an exception (using teardown_request instead).
Thanks
Related
One particular function in my Django server performs a lot of computation during a request and that computation involves a lot of local variables. When an error is thrown during the computation, Django spits out all the function's local variables onto the error page. This process takes Django 10-15 seconds (presumably because of the number/size of my local variables)...
I want to disable the error page for just that particular function, so I can get to see the simple stacktrace faster.
I tried using the sensitive_variables decorator but that doesn't do anything when DEBUG=True.
I also tried simply catching the exception and throwing a new exception:
try:
return mymodule.performComputations(self)
except Exception as e:
raise Exception(repr(e))
but Django still manages to output all the local variables from the performComputations method.
My only option right now is to set DEBUG=False globally anytime I'm actively developing that particular code flow / likely to encounter errors. Any other suggestions? Thanks!
When using the Emberfire (Firebase) adapter, I'm getting various errors that indicate the tests are not waiting for data operations to complete.
eg: Error: Assertion Failed: You can only unload a record which is not inFlight. when I try to create, check, and then delete a record
Also:
FIREBASE WARNING: Exception was thrown by user callback. Error: Called stop() outside of a test context at Object.extend.stop (http://localhost:4200/assets/test-support.js:3000:10) at exports.default._emberTestingAdaptersAdapter.default.extend.asyncStart
These errors do not occur while manually navigating through my app, nor when using the standard ember data adapter.
What is causing these errors and how do I avoid them?
Edit: although the symptoms are a bit different (no error thrown), it sounds like this problem may have the same root cause as the errors I've been seeing.
tl;dr
To work around the issue, I've been using a custom test waiter. You can install it with ember install ember-cli-test-model-waiter (works with Ember v2.0+)
Longer answer:
The root cause of these problems is that the ember testing system doesn't know how to handle Firebase's asynchronicity. With most adapters, this isn't a problem, because the testing system instruments AJAX calls and ensures they have completed before proceeding, but this doesn't work with Firebase's websockets communication.
So although these errors don't occur when interacting manually, I believe they technically could if it were possible to click fast enough.
These problems are known to occur with ember-pouch and will likely also occur with other non-AJAX adapters (eg. localstorage adapters (1, 2), or any other websockets-based adapter. It may occur with the fixture adapter, but that may return results immediately and so not trigger this problem). It also happens with other asynchronous processes, like liquid-fire animations (fixed in a similar way)
The custom test waiter I mentioned in the tl;dr works by waiting for all models to resolve before proceeding with the test, and so should work with all of these non-AJAX adapters.
For more background on how ember's testing deals with asynchronicity under the hood, Cory Forsyth has a helpful blog post, and this gist gives another more flexible solution approach but that requires more manual book-keeping.
As title, when to use httptest.Server and httptest.ResponseRecorder?
It seems to me that I can also test my handlers to return correct response using httptest.Server. I can simply start a httptest.Server given with my implementation of handlers, then do validations on the response's body.
Please correct if I'm wrong, I am learning Go + TDD
When you just want to check, if your http.Handler does what it should, you don't need to use httptest.Server. Just call your handler with an httptest.ResponseRecorder instance and check the output as in the example.
The possible uses of httptest.Server are numerous, so here are just a couple that come to my mind:
If your code depends on some external services and APIs, you can use a test server to emulate them. (Although I personally would isolate all code dealing with external data sources and then use them through interfaces, so that I could easily create fake objects for my tests.)
If you work on a client-server application, you can use a test server to emulate the server-side when testing the client-side.
How can I get Django 1.0 to write all errors to the console or a log file when running runserver in debug mode?
I've tried using a middleware class with process_exception function as described in the accepted answer to this question:
How do you log server errors on django sites
The process_exception function is called for some exceptions (eg: assert(False) in views.py) but process_exception is not getting called for other errors like ImportErrors (eg: import thisclassdoesnotexist in urs.py). I'm new to Django/Python. Is this because of some distinction between run-time and compile-time errors? But then I would expect runserver to complain if it was a compile-time error and it doesn't.
I've watched Simon Willison's fantastic presentation on Django debugging (http://simonwillison.net/2008/May/22/debugging/) but I didn't see an option that would work well for me.
In case it's relevant, I'm writing a Facebook app and Facebook masks HTTP 500 errors with their own message rather than showing Django's awesomely informative 500 page. So I need a way for all types of errors to be written to the console or file.
Edit: I guess my expectation is that if Django can return a 500 error page with lots of detail when I have a bad import (ImportError) in urls.py, it should be able to write the same detail to the console or a file without having to add any additional exception handling to the code. I've never seen exception handling around import statements.
Thanks,
Jeff
It's a bit extreme, but for debugging purposes, you can turn on the DEBUG_PROPAGATE_EXCEPTIONS setting. This will allow you to set up your own error handling. The easiest way to set up said error handling would be to override sys.excepthook. This will terminate your application, but it will work. There may be things you can do to make this not kill your app, but this will depend on what platform you're deploying this for. At any rate, never use this in production!
For production, you're pretty much going to have to have extensive error handling in place. One technique I've used is something like this:
>>> def log_error(func):
... def _call_func(*args, **argd):
... try:
... func(*args, **argd)
... except:
... print "error" #substitute your own error handling
... return _call_func
...
>>> #log_error
... def foo(a):
... raise AttributeError
...
>>> foo(1)
error
If you use log_error as a decorator on your view, it will automatically handle whatever errors happened within it.
The process_exception function is called for some exceptions (eg: assert(False) in views.py) but process_exception is not getting called for other errors like ImportErrors (eg: import thisclassdoesnotexist in urs.py). I'm new to Django/Python. Is this because of some distinction between run-time and compile-time errors?
In Python, all errors are run-time errors. The reason why this is causing problems is because these errors occur immediately when the module is imported before your view is ever called. The first method I posted will catch errors like these for debugging. You might be able to figure something out for production, but I'd argue that you have worse problems if you're getting ImportErrors in a production app (and you're not doing any dynamic importing).
A tool like pylint can help you eliminate these kinds of problems though.
The process_exception function is
called for some exceptions (eg:
assert(False) in views.py) but
process_exception is not getting
called for other errors like
ImportErrors (eg: import
thisclassdoesnotexist in urs.py). I'm
new to Django/Python. Is this because
of some distinction between run-time
and compile-time errors?
No, it's just because process_exception middleware is only called if an exception is raised in the view.
I think DEBUG_PROPAGATE_EXCEPTIONS (as mentioned first by Jason Baker) is what you need here, but I don't think you don't need to do anything additional (i.e. sys.excepthook, etc) if you just want the traceback dumped to console.
If you want to do anything more complex with the error (i.e. dump it to file or DB), the simplest approach would be the got_request_exception signal, which Django sends for any request-related exception, whether it was raised in the view or not.
The get_response and handle_uncaught_exception methods of django.core.handlers.BaseHandler are instructive (and brief) reading in this area.
without having to add any additional
exception handling to the code. I've
never seen exception handling around
import statements.
Look around a bit more, you'll see it done (often in cases where you want to handle the absence of a dependency in some particular way). That said, it would of course be quite ugly if you had to go sprinkling additional try-except blocks all over your code to make a global change to how exceptions are handled!
First, there are very few compile-time errors that you'll see through an exception log. If your Python code doesn't have valid syntax, it dies long before logs are opened for writing.
In Django runserver mode, a "print" statement writes to stdout, which you can see. This is not a good long-term solution, however, so don't count on it.
When Django is running under Apache, however, it depends on which plug-in you're using. mod_python isn't easy to deal with. mod_wsgi can be coerced into sending stdout and stderr to a log file.
Your best bet, however, is the logging module. Put an initialization into your top-level urls.py to configure logging. (Or, perhaps, your settings.py)
Be sure that every module has a logger available for writing log messages.
Be sure that every web services call you make has a try/except block around it, and you write the exceptions to your log.
http://groups.google.com/group/django-nashville/browse_thread/thread/b4a258250cfa285a?pli=1
If you are on a *nix system you could
write to a log (eg. mylog.txt) in python
then run "tail -f mylog.txt" in the console
this is a handy way to view any kind of log in near real time
I'm designing a WCF service that will return a response code (such as 0 for success, or another number for errors). Also, all methods of the web service will perform several common validations (such as authenticating an apiKey).
I am wondering if there is a best practice approach or organizing and retrieving these response codes and messages.
Thanks for any suggestions.
Ideally, don't use response codes. Return something usable on success (or void) and throw an exception on failure.
People deal with exceptions. We often forget to look at returned codes, especially when 99% of the time it's success, and we don't care about any response. So we don't capture. Then we don't bother checking for failure. Then we spend 2 days tracking down a bug that we can't find because no exception was thrown and we have no idea where the 600,000 line application failed that used your webservice... we don't even know it was a call to your webservice that failed. Just that some data is wrong for some unknown reason.
There's a topic on SO about this: Which and Why do you prefer Exceptions or Return Codes
Don't use return codes directly. Return codes usually mean success, set of expected fails and unexpected fail. Web services replace this mechanism with expected faults and unexpected faults. Check FaultContract and FaultException<T> for implementation details for expected faults. Unexpected fault is any other exception. That is the best practice.