Кластер помилки це дуже хороша ідея і задумка, яка була вдало впроваджена в LabVIEW.
Я знаю кілька переваг використання кластера помилки:
- Використовувати як умова для виконання наступних дій:
Тобто якщо кожну блокову діаграму подпрібора взяти в умовну структуру залежне від виконання попереднього подпрібора, то всі наступні подпрібори просто не будуть виконуватися, а помилка вискочить саме з першого подпрібора. Може бути початківцям напевно важко зрозуміти сенс сказаного вище, але це один з головних принципів просунутих програмістів не тільки в LabVIEW, а й в інших мовах програмування.
- Використовувати в LabVIEW замість структури последования:
Як відомо, LabVIEW відрізняється від текстових мов програмування принципом течії даних, тобто так низиваемих "Data Flow Principle". Це означає, що подпрібор починає своє виконання тоді, коли на всіх його входах є будь-яке значення. Якщо ж входів немає, то подпрібор виконується негайно! Незалежно від того, де в блокової діаграмі він знаходиться: зверху, знизу, зліва чи справа. Так ось, деякі початківці, не до кінця розуміють цей принцип використовують структуру последования, хоча могли б використовувати вхід кластера помилки, тим більше що він дає деякі інші переваги.
- Використовувати для розпізнавання помилок в програмі:
Ну в принципі це його призначення. Я думаю варто почитати документацію LabVIEW, що б зрозуміти що це таке. Крім усього іншого можна створювати файл зі своїм списком по помилках для кожної окремої програми.
eg писал (а): Кластер помилки це дуже хороша ідея і задумка, яка була вдало впроваджена в LabVIEW.
Може бути початківцям напевно важко зрозуміти сенс сказаного вище,
eg писал (а): Використовувати в LabVIEW замість структури последования
хороший принцип, але не завжди діє, не всі ж програми - плоскі, напевно він не буде діяти якщо будуть ДВА і більше ліній кожна зі своїм проводом помилки
eg писал (а): можна створювати файл зі своїм списком помилок для кожної окремої програми
тут це стане в нагоді
Коротенко Олексій писав (а): це типу я, да?
Коротенко Олексій писав (а):
хороший принцип, але не завжди діє, не всі ж програми - плоскі, напевно він не буде діяти якщо будуть ДВА і більше ліній кожна зі своїм проводом помилки
Можна обьеденяйтесь кілька помилкових кластерів в один, хоча може бути це неправильна дія з мого боку.
Ось що я мав на увазі під пунктом номер один:
Зелена рамка - це якраз і є умовне виконання подпрібора. Якщо на вході подпрібора вже була помилка, то він не буде виконуватися.
да, неее, я просто приколовся
eg писал (а): не знаю точно наскільки ти знайомий з
eg писал (а): хоча може бути це неправильна дія з мого боку.
код помилки в кластері - це означає "невірно виконана функція vi"?
По-перше статус визначає чи була помилка чи ні. Ну а якщо статус позитивний, то треба дивитися в номер (тобто код) для визначення типу помилки.
А мені доводилося користуватися кластером помилок при роботі через DSTP. Саме по помилках які він генерував я міг міняти логіку роботи програми. Зокрема з виникаючих помилок наявності / відсутності мережевого інтерфейсу в комп'ютері, в моїй програмі працювала / не працювала частину відповідає за прийом / передачу даних. Використання вилову помилок дозволяло "на ходу" працюючої програми змінювати тип підключення до інтернету, що для кінцевого обладнання не було чимось неправильним.
In LabVIEW We Trust
Завжди використовую кластер помилки, крім того, що через нього реалізується один із способів data flow, так ще і зручно моніторити помилки в великих проектах, що використовують багато обчислень і підпрограм, що викликаються.
IMHO, кластер помилки це реалізація поняття "виключення" Exception з С ++ на грунті LView і dataflow. Наскільки вдала - інше питання.
Try-Catch-Finally сішний зручніше буде, але і складніше, особливо коли використовуються многовложенние виключення.