Отладка без дебагера

[Dukobpa3]

Сообщение от iNils

....Но я не пользуюсь дебагерами....

Вот этот пункт заинтересовал... Я как-то без пошагового выполнения слабо себе отладку представляю. Можешь поделиться опытом?

[iNils]

Трейсами

[Dukobpa3]

Я как-то и то и то использую... Где-то одно удобно, где-то другое. Но спасибо за ответ.

[iNils]

В моей практике, очень редко встречается ситуация, когда мне нужен дебагер (за полгода, ну может быть один раз). Обычно ошибки очевидны.
В данном примере, происходит имитация ситуации, когда передается пустая ссылка на спрайт, который мы хотим добавить.

package ru.inils.sample {
	/*    IMPORT             *///{ /
	import flash.display.*;
	import ru.inils.logger.*;
	//}
	public class NewClassMain extends Sprite {
		/*  * CONSTRUCTOR *      *///{ /
		public function NewClassMain () {
			var s:Sprite;
			test (s);
		}
		//}
		/*  - METHOD PRIVATE     *///{ /
		private function test (s:Sprite):void {
			addChild (s);
		}
		//}
	}
}

Соответственно, я получаю RTE

TypeError: Error #2007: Параметр child не должен быть равен нулю.
	at flash.display::DisplayObjectContainer/addChild()
	at ru.inils.sample::NewClassMain/test()[D:\_Library\_Work\classes.as3\personal\ru\inils\sample\NewClassMain.as:15]
	at ru.inils.sample::NewClassMain()[D:\_Library\_Work\classes.as3\personal\ru\inils\sample\NewClassMain.as:10]

Я его копирую, и вставляю в окно своего логгера Logger:Trace

Логгер парсирует текст и в окно Logger:Stack вставляет стек вызова. Далее, я делаю дабл клик по строкам и разбираюсь почему s был null.

Конечно, данный случай простой и ошибка очевидна. Но RTE у меня случаются редко и как правило такие.

Обычно, ошибки у меня в самом алгоритме, и те трейсы помогают вести полный лог изменений во времени и дают полную картину изменений.
Например, недавно я писал код, где одна область входила в другую и при этом должна была соответствовать ряду правил. Для проверки работы алгоритма, я вызывал тестовую функцию, которая эти правила проверяла и и выводила результат. Если где-то правило не срабатывало, выводился ошибка.
Вот пример имитации (не то, что я делал, а сама суть работы) ошибки

package ru.inils.sample {
	/*    IMPORT             *///{ /
	import flash.display.*;
	import ru.inils.logger.*;
	//}
	public class NewClassMain extends Sprite {
		/*  * CONSTRUCTOR *      *///{ /
		public function NewClassMain () {
			Logger.port = 3040;
			for (var i:int = 0; i < 10; i++) {
				var s:Sprite = new Sprite ();
				if (i == 7) {
					s = null;
				}
				test (i, s);
			}
		}
		//}
		/*  - METHOD PRIVATE     *///{ /
		private function test (i:int, s:Sprite):void {
			try {
				Logger.trace (i, true)
				addChild (s);
			} catch (error:Error) {
				Logger.trace (i, false)
				Logger.traceError (error);
			}
		}
		//}
	}
}

После чего, я анализировал проблемный участок и устранял ошибку.

Порой, причина ошибки кроется в действиях задолго до ее появления. А трейсы помогают все эти действия фиксировать и возвращаться к ним в случаях надобности.

[Dukobpa3]

Круто, что сказать)

Я было подумал что обычный себе трейс используется.

Только я пользуюсь стандартными панельками ФД, которые "стек вызовов", "брекпоинты", "watch" вполне себе удобно. Мне к примеру проще поставить точку останова на участке в котором не уверен, чем писать какие-то юнит-тесты, дожидаясь РТЕ(которых у меня как правило тоже оч мало, а иногда наоборот провоцирую ситуацию чтоб вылетело на проблемном участке. Рефактор какой-то например, что-то изменил, вывалилось куча ошибок, исправил по списку и ок.)

Стек вызовов ведет себя аналогично этому Logger:Trace - Фиксирует что откуда вызывалось и как мы в текущей строчке оказались.

[iNils]

Кому как удобнее. Мне удобнее и быстрее с трейсами, чем разбираться в тонне информации.

Мне к примеру проще поставить точку останова на участке в котором не уверен, чем писать какие-то юнит-тесты, дожидаясь РТЕ

Так речь не идет об RTE. С ней и так все ясно. Хотя, как я писал выше, причина RTE была заложена задолго до ее возникновения. Но дебагер показывает состояние "здесь и сейчас", а он не покажет тебе, что было до RTE.

Вот у тебя область вышла за пределы, которые задаются динамически, например округление не так описал или еще что. RTE не будет. А ты пошлешь эту область на сервер, а он не сможет эту область физически обработать.

Или создал ты 100 экземпляров класса с различными свойствами. И только 5 из них, оказались ошибочными. Ты что, будешь каждый из 100 проверять вручную на соответствие 10 разным правилам при каждой компиляции? Или у тебя состояние объекта меняется от каждого твоего движения мышью и только на 300-ый MOUSE_MOVE у тебя происходит ошибка (речь опять не об RTE, а об ошибке в алгоритме).

[Dukobpa3]

Ну мы слегка о разных вещах говорим. В некоторых случаях действительно не обойтись без юнит-тестов. Но в массе своей мне достаточно стека вызовов и точки останова.

[iNils]

А у меня наоборот )

[etc]

Без дебаггера некорректно работающий код трейсами редко удаётся вылечить.

[iNils]

Значит я уникум