середа, 27 жовтня 2010 р.

використовуйте Error, throw, catch,

ось тут я провтикала і все неправильно нарадила (хоча для дійсно лінивих ;) той варіант буде найкращим).

робити потрібно так (чекаю помідорів від unlarik):


var error: Error = new Error("This call is invalid");
trace(error.getStackTrace());


так взагалі треба писати свою систему виводу дебаг-інформації.

а зовсім правильно описані в тому пості ситуації писати так:


...
throw new Error("This call is invalid");
...

...

try{
...
} catch(error: Error) {
trace(error);
trace(error.getStackTrace());
}

5 коментарів:

  1. да, try/catch у флеші народ чомусь дуже сильно ігнорить, до getStackTrace() не добираючись взагалі. я зараз на його основі взагалі написала дебаггер, який у трейс виводить ім'я класу і номер стрічки, з якої трейс відбувається.

    ВідповістиВидалити
  2. Взагалі штука корисна, але відловивши баги треба його якнайшвидше позбуватися, бо флеш плеєр ці трайкетчі довго обробляє, навіть коли все спрацьовує без помилок. А коли ловить помилку то взагалі на неї неймовірно багато часу витрачає, навіть іноді все крешить. Мабуть тому його і не люблять:)

    ВідповістиВидалити
  3. ну просто більшість проектів не потребує серйозної оптимізації, в них на багато важливішою є юзабіліті і підтримуваність, їх оптимізація зводиться до зменшення півпрозорого арту і конкретної оптимізації якихось окремих кусків. і часто на багато важливіше швидко видати продукт, який буде видавати як можна менше ексепшинів (напряму юзерам з FP Debug і непрямо у вигляді незрозумілої зупинки частини логіки аплікації). зараз постановка задачі для доброї третини флешерів звучить як "наваяти швидко щось примітивне під фейсбук" чи якусь велику нудну стратегічку чи ще щось з купою примітивних юзерських компонент (но не флекс з тих чи інших причин) - і тут якраз дешевше буде напихати всюди трай-кетч, ніж вилизувати і оптимізовувати.

    ВідповістиВидалити
  4. замість цього можна напихати перевірки на null)

    ВідповістиВидалити