| Throwing an exception? [message #1693741] |
Tue, 28 April 2015 00:52  |
Eclipse User |
|
|
|
|
I may have just completely skipped over it in the list of available procedures, but I can't seem to find how to throw exceptions of my own.
|
|
|
|
| Re: Throwing an exception? [message #1695368 is a reply to message #1695186] |
Wed, 13 May 2015 15:12  |
| Eclipse User |
|
|
|
I didn't need anything fancy. I was just trying to find if there was a preferred method for determining my own errors, like more traditional programming. For example, this is what I've written to get around what I want to do (final IF block):
proc "verify-children-v2" [val view] [val pathToitem] [val childrenToVerify] {
let [val item [get-view $view | get-tree | get-item $pathToitem]] {
let [val numChildren [$item | get-property "getItemCount()" -raw]] {
if [$numChildren | gt 0] {
if [$view | equals Outline] {
verify-children-helper $numChildren $childrenToVerify $item "getData().getChildren().OMNodeTreeEditPart[" "].getWidget().getText()"
}
if [$view | equals Enclosures] {
verify-children-helper $numChildren $childrenToVerify $item "getData().getChildren().Object[" "].getLabel()"
}
if [$view | equals XForms] {
verify-children-helper $numChildren $childrenToVerify $item "getData().getChildren().Object[" "].getName()"
}
if [and[$view | not-eq Outline][$view | not-eq Enclosures][$view | not-eq XForms]] {
// Create a bogus error to indicate the view isn't supported yet in case we get this far
UnsupportedViewCalledFromProcedure
}
}
}
}
}
The "solution" I've come up with for now is a bogus call with the name of the error I'd like to display (UnsupportedViewCalledFromProcedure). I've found the lack of control in ECL to be a pain point sometimes, as there is no conventional return. In this case I've written my own little verification for the children of a particular tree element, which needs to be done dynamically and not to any super specific degree. Depending on the tree type, the data is being stored differently. I've only set up 3 initial conditions that will succeed, as this will be added to as needed by other QA. The problem was I didn't want to reach the end of the IFs and return successfully if an unsupported View name was passed in because the procedure should end in error in that case. But, I also wanted an error message specific enough to show why it didn't work if somebody tried to use it. This is what I came up with.
For the record, I still feel like this is kind of a silly way to do it and there is a better way, but it works the way I want and will do for now. Only started this a few weeks ago, so very much a novice when it comes to being familiar with the capabilities.
[Updated on: Wed, 13 May 2015 15:21] by Moderator |
|
|
Powered by
FUDForum. Page generated in 0.04488 seconds
Home