General purpose Error Handler Routines

While developing various applications we found out that error handling is one of the most important(at the same time one of the most ignored) task. so we decided to develop some modules which will allow us to configure the handling methods
after develoment we think that this library can be useful to everyone, hence we are making it public
please feel free to give your feedback, bug report, improvement ideas etc...
you can also mail me at [email protected]
Tushar Jambhekar
[email protected]
Jambhekar Automation Solutions
LabVIEW Consultancy, LabVIEW Training
Rent a LabVIEW Developer, My Blog
Attachments:
Error Handler.zip ‏367 KB

Hello Tushar,
Thanks for sharing your work on the forum. We really appreciate it.
Regards,
Chetan K
Application Engineer
National Instruments

Similar Messages

Equivalent for IBM specific Error handling routines

Hi,
There is a couple of IBM specific error handling routines - AFHCEEN (CEE3SPM) and XUFLOW in our FORTRAN source code which suppresses the overflow and underflow exceptions. Is there any equivalent of these routines available in SUN Solaris O/S ?

Yes, there are two ways to do it. First, if you simply want to suppress those exceptions throughout the code you can compile with -ftrap=%none.
If you need to be able to turn off those exceptions temporarily, then you can use the IEEE_EXCEPTIONS module, which is part of the Fortran standard (and thus ought to be portable). Here is an example:
use ieee_exceptions
real x
integer status
logical m
call get_command_argument(1, status=status)
if (status .eq. 0) then
   print *, 'Enabling signals'
   m = .true.
else
   print *, 'Disabling signals'
   m = .false.
end if
call ieee_set_halting_mode((/ ieee_overflow, ieee_underflow, ieee_inexact /), m)
x = 0.1
do while (x .ne. 0.0)
   x = x / 2.0
end do
endYou should be aware, though, that the standard requires the halting mode to be saved on entry to a procedure and restored on exit. Therefore, you cannot write a subroutine whose purpose is to change the halting mode in the procedure that calls it.

Error Handling Routine

Hi Experts,
Can anyone provide me the error handling routine (package/procedure)? or any link?
At present I am just using the Raise_Application_Error and then handling it in When Others exception clause. But now I need some kind of mechanism which captures all my errors and then send the errors to front end (HTML/Jscript).
Your help would be appreciated.
Thanks,
Ba
London

Remove the WHEN OTHERS clause. The exception will be propagated back to your front-end, as God* intended.
*Larry.

General Labview Error Handler question discussion

Recently two functions were brought to my attention, the General Error Handler and the Simple Error handler.
And I cannot wrap my hand around these two features. While I have been using Labview I have always used the Labview error cluster. When would you use these two features? As I feel the cluster error is much help.
Maybe it is my defnition that I have confused:
The general error handler will display a dialogue box describing the error that will be passed and shuts down the code?
The simple error handler notifys the operator that an error has occured but it can be customized for adding functionality, it takes the error cluster input and determines if an error was generated. "If an error has been generated, the VI displays a dialog box with the error code, a brief description of the error, and the location of the error." How is this not the same as an error cluster?
If anyone has any simple code examples for this or knowledge I greatly appriciate it.
Caleb

Jacobson wrote:
Psireaper9 wrote:
The simple error handler notifys the operator that an error has occured but it can be customized for adding functionality, it takes the error cluster input and determines if an error was generated. "If an error has been generated, the VI displays a dialog box with the error code, a brief description of the error, and the location of the error." How is this not the same as an error cluster?
You are correct that they give the same information. The difference is that if you want to use an error cluster you will need an indicator on your front panel. If you use the simple error handler you won't have to have an error cluster on your front panel but the user will be notified if an error does occur.
Think about all the programs you normally use (excel, chrome, etc.). As a user you expect that errors aren't happening, and if errors do occur then the application will usually just close out and you get an error dialog about the error.
I use the simple error handler with no user interaction to extract the error text. Is there an easier way of doing that?

Error handling routines....

Each,
Have started working on an application which is a couple of years old. Has a 9i backend and currently 6i front end but will be moving to 9i or higher.
It has no built in error handling so am wanting to introduce this without causing too much disruption. Am not wanting to have to change all the calling parameters to the packages.
Am considering creating an error package with private variables to hold any errors raised and using a function which can be called from the client to check for any errors after calls to the server. What do people think about this approach?
Am thinking this would be OK for the user facing part of the app but for batch jobs would need a different approach like storing details away in an error log table.
Any pointers and clues as to what way i should be going?
Thanks In Advance

Hi,
a possible solution for your problem is
-- define your functions and procedures WITH EXCEPTION HANDLING
throwing EXCEPTIONS f.e. with own defined Error-Codes
now your client can handle the exceptions you throw
-- for your batch-jobs you can define "facades"(like FACADE-Pattern) for the
functions, procedures which handle the exceptions throws by the
functions and log the information f.e. in a table.
Hope that helps
Regards
Schoeib

General Error Handling - use of FEH (PPO/ECH)

We are investigating the usage of Forward Error Handling, known with SAP as PPO (Post Processing) and ECH (Error Capture Handler) to be able to re-process errors (automatically or manually) from incoming messages.
I am interested in talking with anyone who has implemented this. General questions are:
- how have you found it to work in real life?
- configuration/set-up straight-forward?
- what scenarios have used it in?
- incorporated into your custom services?
But am interested in any comments.
I am posting this within the PI forum as it ties into the fact we async scenarios inbound to SAP, typically from our PI system, and when those scenarios encounter an error we are looking for a way to have a business/end user - friendly interface for reprocessing the error. Implementing a proxy scenario, and thus having the errors show within sxmb_moni/sxi_monitor, is probably not going to work for us - too technical. I am also aware of an add-on, AIF I believe, but our company is not interested in installing that.
There are 4 blogs out there that I am aware of - 2 from Tobias and 2 from Michal. Very informative. I am finding some config not as ours though. Am really interested in anyone has really implemented and used this in a prod environment.
Regards,
Keith

I think I am exactly at the same position as you in figuring out the usage of FEH in an environment. I just completed a small document (for internal purpose) that I prepared gathering all the information from those blogs, SCN and TechEd. Here are my 2 cents:
>>- how have you found it to work in real life?
We haven't implemented it yet. But we believe it will be quite useful in handling business specific errors. We are trying to find out if it can be merged with the existing BPEM infrastructure to generate BPEM cases.
>>- configuration/set-up straight-forward?
Yes, the blogs should be quite useful to provide this information.
>>- what scenarios have used it in?
Most importantly it will be used for standard service implementation where we consume enterprise services from ES workplace. These services have FEH capability built in (they have FEH method implemented within). The scenarios are of course inbound abap proxy.
>>- incorporated into your custom services?
We are still in design phase. But if you ask me about it, i would say yes you can and I think you should use it for custom ones as well.
Kind regards,
Prateek Raj Srivastava

General QUestion about error handling

Hello,
I am writing my own VI's to communicate with my hardware. Each one of the VI's incorporate numerous error checking routines to detect if the desired operation completed correctly. If error(s) are detected with a VI, the "Bundle by Name" VI is used to update the Natiinal Instruments error cluster with the appropriate info each time a error occurs.
What I am finding is that the VI error cluster contains the last error found, instead of the first error found. Please be aware that I am assuming (we know what that stands for) is that the National Instruments error cluster is accumulative, so if I add four errors to the cluster, then the error cluster contains at least four errors.
So how do I find the first error that was entered into the error cluster. I have found a vi called "Find First Error:, but I am confused (as usual) on how to get what I want. So I am asking for "divine guidance" or a kick in behind from the Labview wizards on how to correctly handle errors.
Regards,
Kaspar
Regards,
Kaspar

The cluster is a standard cluster and is not accumulative.
Usually, the way to handle this is to check the error in terminal and if it is has an error to pass the error instead of executing the code. That way, when you have an error, the rest of the code does not execute. Here's an example:
If you want to merge the error numbers, search the forums for Mike Porter's error stacker.
Try to take over the world!

General Inquiry Regarding Error Handling with System Exec.vi

I have a sub vi that uses the System Exec.vi to send SMS messages when triggered. I am confused as to how the error handling works and why all of the errors seem to go to the "standard error" vs the "Error out". The reason I am interested is because I am trying to interrupt the error out of another script to execute a command if error=true.
I have intentionally created an error to test this, however it does not seem that the signal is ever being sent to the error out, only to the standard error.
Any help/explanation as to how this works would be greatly appreciated.

The Facebook discussion board is just a pilot and that functionality is not available yet (as to my knowledge). You will have to use the actual forum thread to add attachments. You can click the arrow just to the right of thread topic in the Facebook thread and that will take you to the ni.com/forums thread. Or you can navigate here:
http://forums.ni.com/t5/LabVIEW/General-Inquiry-Regarding-Error-Handling-with-System-Exec-vi/m-p/246...
Having a look at your VI would help to clarify the error handling issue.
Daniel K | NI Applications Engineer | Certified LabVIEW Developer

How to add sound to the general error handler

I'm looking for an easy way to create an audible indication (a beep or something) when the general error handler displays an error message. Anyone have any suggestions??
Solved!
Go to Solution.

Hi Bill,
I thought this was an interesting idea, so I wrote up the code and posted it on the NI Community here: Simple Error Handler with Beep. If you have any cool VIs that you'd like to share, you can post them on the community as well to share them with others. Thanks!
Stephen Meserve
National Instruments

General error handling operation

Hi,
I did not find a comprehensive explanation how error handling works in TestStand, only bits and pieces about the callbacks (perhaps I looked at the wrong places).
Anyway, I made some experiments with SequenceFilePostStepRuntimeError and StationPostStepRuntimeError - intentionally leaving out ProcessModelPostStepRuntimeError to reduce complexity - and came up with the attached flow chart. I would like to know:
if that shows the correct operation of TestStand error handling (we are currently using 4.1, about to switch to 2010 or 2012, so it would also be interesting to know if anything changes with the new versions)
if it is always the case that the combination of ErrorReported=True und Error.Occurred=True after the error handler leads to termination of the execution? I could not find any setting governing that (the "goto cleanup immediately" setting of the sequence was off;
Best regards
Peter
Attachments:
TestStand_ErrorHandling.png ‏36 KB

Hi Peter,
1) Every step has :
error.code - to set the error code
error.occured - boolen if set true displays a popup error message to the user
error.message - the popup contains this message
when you set error.occured=true it will bring up a popup message with the error.message and error.code.
Please note that this may not be acceptable in the manufacturing environment where operators may not be trained to check for errors.
The general practice in manufacturing is to fail all important steps that errors out so that the final result is failed.Then do a offline analysis.This is done by step.results.status = "Failed".You can also populate step.results.ReportText with proper values so that your test report reflects the type of error/failure.
2) Regarding the SequenceFilePostStepRuntimeError and StationPostStepRuntimeError - they are optional error handling methods if you want to act on errors.
3)Every step has an option ( look for properties-->post actions).On Pass or On fail destinations can be set for each step.Cleanup is always executed except in cases of abort.
4) In the menu configure-->Station options-->execution there is an option for runtime errors ( one of them is run cleanup).
Hope the above information helps.

Using the general error handler on an embedded rt target

I would like to know how the general error handler can be best employed
with Labview RT on a Compact Fieldpoint controller. Clearly no
dialogue options are valid so how can error information be accessed
remotely - is there an error log file available on the controller?

I think there are plenty of ways to handle errors with Labview RT on a Fieldpoint controller.
Usually I use the general error handler vi to catch the error and get the error message (sure, no dialog), then write the eroor message into a log file (ordinary text file created on the controller), and/or send the eroor message through TCP/IP network to the host. You can use FTP to open, read and tranfer the log file at host. Hope help.
Xu

General Error handling

I've managed to get myself confused with error handling in Forms 6i.
If I have a trigger that does a 'commit-form' like this
commit_form;
IF NOT form_success THEN
RAISE form_trigger_failure;
END IF;
EXCEPTION
WHEN OTHERS THEN;
END;
and the commit_form fails due to a mandatory field being missing (or similar) then what happens first?
Does my ON-ERROR trigger fire?
Does the form_success check fail and raise form_trigger failure?
Does my exception block get used?
Or does more than 1 happen??
I could - of course - find the answer to this through debug but I'm looking for a more generic answer if possible.
Thanks - Sean.

What happens first? The forms validation process runs and informs user that the field is required.
Does On-Error fire? Yes, if you have one in your form.
Does the form_success check fail and raise form_trigger failure? Yes -- but ONLY if your On-error raises Form_trigger_failure. If it does not, you have lots of problems.
Does my exception block get used? Yes. Raising Form_trigger_failure causes control to pass to the exception handler. But I never use an exception handler except when I code SQL commands.
Now... After commit_form, you should also check Form_Status. Read the help topic on the Form_Success built-in.
My standard C00_Commit program unit does this:
COMMIT_FORM;
IF :SYSTEM.FORM_STATUS <> 'QUERY'
OR NOT FORM_SUCCESS THEN
RAISE FORM_TRIGGER_FAILURE;
END IF;
END;

How to implement general error handler in labview projects

Thanks,

Hello,
You may also find these links useful:
Custom Error Handling In LabVIEW
http://zone.ni.com/devzone/conceptd.nsf/webmain/de4f036f22c4b9f286256fee0010b6fd
LabVIEW Introduction Course - Six Hours (has a section on error handling)
http://zone.ni.com/devzone/learningcenter.nsf/03f7c60f17aad210862567a90054a26c/55974411828f779086256...
Hope this helps!
Charlie S.
Visit ni.com/gettingstarted for step-by-step help in setting up your system

Understanding how Error handling works in transformation

Hi Experts,
I am trying to achieve error handling in Start and End Routine by writing the error log to the monitor and also raising the exception in case a match is not found.
I understand the code below achieves what I am looking for, but I want to know how this works
if sy-subrc ne 0.
        monitor_rec-msgid = 'BI'.
        monitor_rec-msgty = 'E'.
        monitor_rec-msgno = '001'.
        monitor_rec-msgv1 = 'No entry for ZTYPE in source '.
        monitor_rec-msgv2 = .
        append monitor_rec to MONITOR.
        raise exception type CX_RSROUT_ABORT.
      endif.
Can someone please explain how the above code works?
I am not sure how these messages get written to the monitor and how to check these error records. Also if a load is scheduled in the process chains, does the DTP error log show the exception CX_RSROUT_ABORT?

proper exception handling is one of the most important thing to consider in your pl/sql code.
One basic principle is to trap/handle only those exceptions that you expect. In general this means you should NOT use the when other execption (only at the outermost call structure)
I guess this is oracle FORMS pl/sql, so we have to be careful with some assupmtions.
But this should work. See also how indenting the ode helps to improve readability. Here in the forum you need to use {<b></b>code} tages before and after your code to preserve indention and to enable basic highlighting
untested
/* fetch the primary account */
begin
   select customer_code into cust from primary_account where pc.customer_code=:import_can.consignee_code;
exception
   when no_data_found then
      j:='Customer ('||:import_can.consignee_code||') not found. Account is not created for this consignee ';
      raise_application_error(-20001,j); /* might be raise form_trigger_error here or something like that */
   when too_many_rows then
      j:='Customer ('||:import_can.consignee_code||') has several Accounts!';
      raise_application_error(-20001,j);
end;
begin
     select customer_code into cust from cust_details where customer_code=:import_can.consignee_code;
exception
    when no_data_found then
        h:='consignee_code is not exist in customer code';
       raise_application_error(-20001,h);
end;
COMMIT_FORM;
:GLOBAL.ADDCAN:=0;
SA:=SHOW_ALERT('SAVE');
ENAB;

Advanced Error handling

Hi all,
I am developing an error handling system for an extensive LabView application, unfortunately I can't call it's purpose due to confidentiality.
I just graduated for my university degree in Applied Physics, and therefore I am pretty experienced with LabVIEW (got core 1,2 and 3).
The used synchonization technique is a queue-operated producer/consumer handler. The testing set-up consists out of the following hardware:
- Keithley 2700 multimeter
- A Stanford SR830 Lock-in
- PI-Mercury 863 (Z-stage controller, for moving up and down)
- NI DAQ 6244
My Question is:
How can you make sure that you cover most errors with your error handling application? What would be a correct approach to find all possible errors that could occur during a measurement?
For example: I could disconnect the K2700 and start the application, then a VISA error is most likely to occur. Besides that I could disconnect the power supply of the hardware and start the application and see which error would occur then.
Is there some general kind of rule of thumb to find the possible errors which could occur in the set-up?
Thanks for your reply in advance.
Cheers,
San
Solved!
Go to Solution.

Aha! Found it: https://decibel.ni.com/content/docs/DOC-20726
I think that was the presentation that I was trying to find earlier as it gives some information about actual strategies for dealing with errors and reporting them versus just how to wire up error wires and the general error handler.
As for your reply, you need to think about grouping sections of code and say to yourself "what should happen if an error occurs here?". You will probably end up identifying gating points in your code (e.g. at the end of a case)
As a couple of examples:
- During initialisation, if a device fails to initialise, should you retry and if so, how many times before giving up? Should you let the user attempt to reconfigure the device
- If you're using a queue based architecture and the reference gets destroyed
You end up having to analyse your code and saying "What if....?" a lot!
I think the errors boil down to something like the following:
- Critical application errors: A terminal error caused by a software bug such as accidentally releasing a reference to a main message queue. In this case you have to shut-down the software but you should report or log some information to help you debug the issue remotely!
- Device errors: Failed to initialise, device not present, lost connection, incorrect configuration - the software can't operate normally but maybe you could keep trying to re-initialise or allow the user to try to change settings rather than exit the application.
- User errors: User has misconfigured something such as entered an invalid path or selecting an incorrect file (type, format etc.) - in this case you should probably notify the user and let them try again.
- Known errors: errors that you expect might occur such as creating a folder that already exists - these would usually be ignored or handled in a case structure. Another example of this is errors out of 'close' subVIs in your exit case (the device might never have initialised or may have already shut down)
You'll never be able to catch every single error (and it's not possible to see all errors a VI might produce and you may want to generate your own errors) but you should try to properly handle (& rectify) errors that are more likely to occur (such as lost connection to a device because someone tripped over a serial cable) and leave the other errors to your general handler.
You also want to think about the experience for the end user of your software - something that the presentation linked above mentions. Chances are that the average user isn't going to be able to understand LabVIEW error codes and will be disappointed if the software just shuts down on launch because a device is missing.
There is no holy grail of error handling/reporting - it's something I'm always reading/learning about and try to apply that as much as I can in my applications!
Certified LabVIEW Architect, Certified TestStand Developer
NI Days (and A&DF): 2010, 2011, 2013, 2014
NI Week: 2012, 2014
Knowledgeable in all things Giant Tetris and WebSockets

General purpose Error Handler Routines

Similar Messages

Maybe you are looking for