CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am: Difference between revisions
| Line 4: | Line 4: | ||
2)Errors early in flow might manifest itself late. | 2)Errors early in flow might manifest itself late. | ||
For example, | For example, | ||
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 have happened a long time ago. | 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. | ||
| Line 16: | Line 16: | ||
You can do anything you want in development mode. Print errors to the terminal, which will go by very quickly and it’ll be hard to read. Writing to log file works both in development mode and production mode. Interactive debugger stops the app in its tracks and inspects the state of the variables and then continue.'' | You can do anything you want in development mode. Print errors to the terminal, which will go by very quickly and it’ll be hard to read. Writing to log file works both in development mode and production mode. Interactive debugger stops the app in its tracks and inspects the state of the variables and then continue.'' | ||
===Definitions=== | ===Definitions=== | ||
Revision as of 03:58, 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 type of user. 1) What Dev? Prod? Printing to terminal Y Logging Y Y Interactive Debugging Y
You can do anything you want in development mode. Print errors to the terminal, which will go by very quickly and it’ll be hard to read. Writing to log file works both in development mode and production mode. Interactive debugger stops the app in its tracks and inspects the state of the variables and then continue.
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.