Как «выбросить»% Status в% ETN? - PullRequest
Новая
       17

Как «выбросить»% Status в% ETN?

2 голосов
/ 06 октября 2011

Многие из методов API Caché возвращают объект% Status, который указывает, является ли это ошибкой. Дело в том, что, когда это неизвестная ошибка, я не знаю, как ее обработать (например, сбой сети), что я действительно хочу сделать, это «выбросить» ошибку, чтобы мой код прекратил свою работу, и ошибка была обнаружена некоторыми более высокими обработчик ошибок уровня (и / или встроенный журнал ошибок% ETN).

Я мог бы использовать ztrap как: 

s status = someObject.someMethod()
ztrap:$$$ISERR(status)

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

Ответы [ 2 ]

2 голосов
/ 28 октября 2011

Взгляните на ссылку класса для% Exception.StatusException. Вы можете создать исключение из вашего состояния и выбросить его в любую ловушку ошибок, активную в данный момент (поэтому поток управления будет таким же, как в вашем примере ZTRAP), например, 

set sc = someobj.MethodReturningStatus()
if $$$ISERR(sc) {
   set exception = ##class(%Exception.StatusException).CreateFromStatus(sc)
   throw exception
}

Однако, чтобы восстановить информацию об исключении внутри кода прерывания ошибки, который перехватывает это исключение, должно быть установлено прерывание ошибки с помощью try / catch. Старые обработчики ошибок, $ ztrap и $ etrap, не предоставляют вам объект исключения, и вы только увидите, что в качестве значения $ ZERROR у вас есть ошибка . Даже в этом случае поток управления будет работать так, как вы хотите, но без try / catch вам будет не лучше, чем с ZTRAP

1 голос
/ 07 октября 2011

Это два разных механизма ошибок, которые нельзя объединить таким образом.ztrap и% ETN предназначены для ошибок уровня кэша (ошибки в угловых скобках, например <UNDEFINED>).Объекты% Status предназначены для ошибок уровня приложения (в том числе ошибок, возникших в результате использования библиотеки классов кэша), и вы можете сами выбирать, как их обрабатывать.На самом деле не имеет смысла обрабатывать плохой% Status с помощью механизма ошибок Cache, потому что ошибки Cache не произошло.

Обычно то, что делает большинство людей, похоже на:

d: $$$ ISERR (статус) $$$ SomeMacroRelevantToMyAppThatWillHandleThisStatus (статус)

Возможно создать свойсобственный домен со своим собственным хостом кодов% Status с соответствующими значениями% msg для вашего приложения.Ваше приложение, возможно, пыталось подключиться к FTP-серверу и имело неверный пароль, но это не выдает <DISCONNECT>, и нет никаких причин для исследования стека, просто ошибка уровня приложения, которая должна быть обработана, возможно,просит пользователя ввести новый пароль.

Может показаться странным, что существуют эти два параллельных механизма ошибок, но они описывают два разных типа ошибок.Думайте, что одна из них - это ошибки уровня «платформы», а другая - «ошибки уровня приложения»

Редактировать: Одна вещь, которую я забыл, попробуйте DecomposeStatus ^% apiOBJ (status) или ## class (% Status).LogicalToOdbc (status) для преобразования объекта статуса в удобочитаемую строку.Кроме того, если вы выполняете отладку командной строки или просто хотите распечатать читаемую форму на основном устройстве, вы можете использовать $ system.OBJ.DisplayError (status).

...