CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 22: Line 22:
==RASP==
==RASP==


===Steps of RASP===
===Tips to deal with an error===
i) Read the error message. Really read it.
i) Read the error message carefully.
The error message is trying to tell you something so read it.
ii)Ask your colleague an informed question in case you are doing pair programming.  
 
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
iii) Search using StackOverflow or Google
Especially if its an error which is particular to a version of gems or OS
Especially if its an error which is particular to a version of gems or OS
iv) Post on StackOverflow or class forum
iv) Post on StackOverflow or class forum
Get minimal but complete information which reproduces the error message which you are experiencing and post it.
Get minimal but complete information which reproduces the error message which you are experiencing and post it.

Revision as of 04:37, 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.

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.

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.

Interactive Debugging

In this approach you can stop the application in its track and inspect the variables or other parameters to locate the error.

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.

Understanding Error Messages in Rails

Application Trace

Back Trace

Full Trace

Env Dump and Session Dump

Most Common Error Messages in Ruby

Interactive Debugger

What is an interactive debugger?

Conclusion

Further Reading

References