CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am: Difference between revisions
| Line 6: | Line 6: | ||
Consider the following hierarchy: | Consider the following hierarchy: | ||
URI -> Route -> Controller -> model -> view -> renderer | URI -> Route -> Controller -> model -> view -> renderer | ||
Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might | Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago. | ||
3) Error can be hard to localize/reproduce if it affects only some users or routes. | 3) Error can be hard to localize/reproduce if it affects only some users or routes. | ||
There are several approaches that can be used for debugging on Saas depending on the | There are several approaches that can be used for debugging on Saas depending on the mode of operation. | ||
===1)Printing to terminal=== | |||
Printing to terminal | In development mode the user is the master and he can easily debug using this approach. This is not possible in production mode though. | ||
===2)Logging=== | |||
This is a more general approach. The logged entries are permanent record of what your application is doing. The recorded errors can also be used to be referenced later. This approach can be used both in the development mode as well as the production mode. | |||
===3)Interactive Debugging=== | |||
In this approach you can stop the application in its track and inspect the variables or other parameters to locate the error. | |||
===Definitions=== | ===Definitions=== | ||
Revision as of 04:22, 17 November 2012
Introduction
Debugging in SaaS/Rails can be tricky
1) Some people are used to printing the error on the terminal(ex. Standard error). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses. 2)Errors early in flow might manifest itself late.
For example, Consider the following hierarchy: URI -> Route -> Controller -> model -> view -> renderer Here, something that goes wrong in the controller might not manifest itself until the renderer. The root cause of the error might have happened a long time ago.
3) Error can be hard to localize/reproduce if it affects only some users or routes.
There are several approaches that can be used for debugging on Saas depending on the mode of operation.
1)Printing to terminal
In development mode the user is the master and he can easily debug using this approach. This is not possible in production mode though.
2)Logging
This is a more general approach. The logged entries are permanent record of what your application is doing. The recorded errors can also be used to be referenced later. This approach can be used both in the development mode as well as the production mode.
3)Interactive Debugging
In this approach you can stop the application in its track and inspect the variables or other parameters to locate the error.
Definitions
RASP
Steps of RASP
i) Read the error message. Really read it. The error message is trying to tell you something so read it.
ii) Ask colleague Ask your colleague an informed question in case you are doing pair programming. I am trying to do this and I expected it to do this but I got this other thing instead of foo.
iii) Search using StackOverflow or Google Especially if its an error which is particular to a version of gems or OS
iv) Post on StackOverflow or class forum Get minimal but complete information which reproduces the error message which you are experiencing and post it.