%objlasterror is a useful reference to the last error.
Every time $$$ERROR is called, %objlasterror is set to a result of this call.
It's important in cases where you want to convert exception to status:
Try {
// quality code
} Catch ex {
Set sc = $g(%objlasterror, $$$OK)
Set sc = $$$ADDSC(sc, ex.AsStatus())
}
Because AsStatus calls $$$ERROR under the wraps, the order is important, first you need to get %objlasterror and convert exception after that.
For Java gateway this method of handling exceptions also works:
If ((ex.Name="<ZJGTW>") && $d(%objlasterror)) {
Set sc = %objlasterror
} Else {
Set sc = ex.AsStatus()
}
Just a quick note: when errors are processed consistently, e.g. each %Status have been returned is processed with $$$TOE or $$$ThrowOnError or $$$ThrowStatus macro, this approach seems to be excessive, and `set sc=ex.AsStatus()` is just enough. E.g.
For me, unexpected %objlasterror is no more than a sign of inaccurate coding, when some %Status values are not processed.
Depends on a coding style.
I prefer not to use/propagate exceptions, but rather %Status.
It seems that try / catch paradigm encourages one to propagate exceptions. Otherwise it's easy to get a "style mix" that looks unpleasant, something like:
or
All this stuff is just IMHO, just an attempt to be consistent.
If one were to write or save %objlasterror's output to a database, how would one interpret these characters:
0 ß!>
I find pretty consistently I get this as part of the output which I can work around but isn't helpful.
I think the WYSIWYG kicked out some chars:.png)
%objlasterror
is%Status
which is a binary format. You can store it in a property of a%Status
type and use ODBC mode for SQL queries, or use$system.Status.DisplayError(sc)
to get/store the display value.Thanks!
Please correct me if I'm wrong but I found
$system.Status.GetErrorText(sc)
was the appropriate method to use overDisplayError()
asDisplayError
simply writes to the console and would not save to the database or a variable.