CSC/ECE 517 Fall 2012/ch2b 2w-1w65 am

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.