CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am: Difference between revisions
| Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
This is a wiki article for the material presented in the Coursera SaaS video series, 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson. We aim to cover all the material presented in the video with definitions and examples<br><br> | |||
'''Why debugging in Rails can be tricky?'''<br> | |||
*We are used to printing the error on the terminal in most applications(Example: STDERR). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses. | |||
*Errors early in flow might manifest itself late. | |||
Consider the following hierarchy seen in a Rails application: | |||
URI -> Route -> Controller -> Model -> View -> Renderer | |||
URI -> Route -> Controller -> | |||
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. | ||
*Errors can be hard to localize/reproduce if it affects only some users or routes. | |||
There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode: | |||
'''Printing to terminal:'''This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode.<br> | |||
'''Logging:''' This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later.<br> | |||
This is a more general approach. The logged entries are permanent record of what | |||
'''Interactive Debugging:''' Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error.<br> | |||
Here is a summary of the various approaches and the modes in which they can be used: <br> | |||
{| class="wikitable" | |||
|- | |||
! Approach !! Development !! Production | |||
|- | |||
| Printing to Terminal || ✓ || | |||
|- | |||
| Logging || ✓ || ✓ | |||
|- | |||
| Interactive Debugging || ✓ || | |||
|} | |||
==RASP== | ==RASP== | ||
Revision as of 23:00, 17 November 2012
Introduction
This is a wiki article for the material presented in the Coursera SaaS video series, 3.13 Debugging by Dr. Armando Fox and Dr. David Patterson. We aim to cover all the material presented in the video with definitions and examples
Why debugging in Rails can be tricky?
- We are used to printing the error on the terminal in most applications(Example: STDERR). This may not be possible for a web application since its primary form of input and output is through HTTP requests and responses.
- Errors early in flow might manifest itself late.
Consider the following hierarchy seen in a Rails application:
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.
- Errors can be hard to localize/reproduce if it affects only some users or routes.
There are several approaches that can be used for debugging based on the mode of operation, that is development mode or production mode:
Printing to terminal:This is useful for developers, when they are writing code they can print errors to the terminal and then examine them. We cannot use this approach in production mode.
Logging: This is a more general approach to debugging which can be used in both modes. The logged entries are permanent record of what the application is doing. The recorded errors are saved in a log file and can be referenced later.
Interactive Debugging: Using this tool you can stop the application in its tracks and inspect the state of the variables or other parameters to locate the error.
Here is a summary of the various approaches and the modes in which they can be used:
| Approach | Development | Production |
|---|---|---|
| Printing to Terminal | ✓ | |
| Logging | ✓ | ✓ |
| Interactive Debugging | ✓ |
RASP
Tips to deal with an error
i) Read the error message carefully.
ii) Ask your colleague an informed question in case you are doing pair programming.
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.