torekp Posted February 14, 2009 Report Share Posted February 14, 2009 Often times I get error messages from attempting to read a file that doesn't exist. Sometimes Labview tells me, in the error message, what file I tried to read; sometimes it doesn't. That piece of information is very useful, so I want to start writing all my code in such a way that if this error happens, I get that information. Does it just depend on which of Labview's many file functions I use? Does anybody know which ones are user-friendly and which ones are cryptic, when this error occurs? If there's something else going on, what is it? Quote Link to comment
Donald Posted February 14, 2009 Report Share Posted February 14, 2009 FYI: If I get this error and it is not clear which file (e.g. Application Builder, not your app, ...) I use the Sysinternals free FileMonitor. it reveals on OS level the calls to missing files (the same exists for registry). Quote Link to comment
jdunham Posted February 14, 2009 Report Share Posted February 14, 2009 QUOTE (torekp @ Feb 13 2009, 05:09 AM) Often times I get error messages from attempting to read a file that doesn't exist. Sometimes Labview tells me, in the error message, what file I tried to read; sometimes it doesn't. That piece of information is very useful, so I want to start writing all my code in such a way that if this error happens, I get that information.Does it just depend on which of Labview's many file functions I use? Does anybody know which ones are user-friendly and which ones are cryptic, when this error occurs? If there's something else going on, what is it? I don't think there's anything else going on. Some of NI's error handling is totally crappy, and some is just lame. Where's the call chain, or ability to insert arbitrary run-time data (like the filename), and have it auto-labeled? The functions for generating errors and clearing errors are worthless. For example the Clear Errors function clears any error, not just one matching the error code(s) you might be expecting. Part of the problem was that the original design (the error cluster itself) was not flexible enough, and another part is that they never use typedefs for internal functions, so there's no way for them to change a data structure like that once it's let loose. (I guess that could have consequences for reading old versions of the typdefs back from files, but I think they could have worked around that). If you poke around the NI stuff, you can see they have a sort of syntax for adding items like the file name, so you can write code that detects a new error, and adds the info you care about to the error.source field in the format that their dialog boxes understand. Quote Link to comment
Rolf Kalbermatter Posted February 17, 2009 Report Share Posted February 17, 2009 QUOTE (jdunham @ Feb 13 2009, 05:01 PM) iI don't think there's anything else going on. Some of NI's error handling is totally crappy, and some is just lame. Where's the call chain, or ability to insert arbitrary run-time data (like the filename), and have it auto-labeled? The functions for generating errors and clearing errors are worthless. For example the Clear Errors function clears any error, not just one matching the error code(s) you might be expecting. Part of the problem was that the original design (the error cluster itself) was not flexible enough, and another part is that they never use typedefs for internal functions, so there's no way for them to change a data structure like that once it's let loose. (I guess that could have consequences for reading old versions of the typdefs back from files, but I think they could have worked around that). If you poke around the NI stuff, you can see they have a sort of syntax for adding items like the file name, so you can write code that detects a new error, and adds the info you care about to the error.source field in the format that their dialog boxes understand. The fact that there is no typedef for error clusters wouldn't necessarily preclude changing that. They already have special case handling that allows to connect an error cluster to a Selector Node or a case structure Selector, as well as enabling the popup menu about explaining the error. This is all done on the recognition of the specific type definition (as in the type signature not what you understand as typedef on LabVIEW FP level) an error cluster has. But the issues are very complicated. You could create an error structure that allows structured exception handling, error classes and according inheritance and what else you can think of and create a monster in handling it, performance and memory footprint. And typedef or not the real difficulty is about upgrading existing code that comes not from NI. A typedef wouldn't help at all as it still would break tons of code that was crunched together by someone who had no idea about using even the limited facilities of the error cluster in a useful way. Rolf Kalbermatter Quote Link to comment
torekp Posted February 17, 2009 Author Report Share Posted February 17, 2009 QUOTE (jdunham @ Feb 13 2009, 11:01 PM) [...] For example the Clear Errors function clears any error, not just one matching the error code(s) you might be expecting. [...]If you poke around the NI stuff, you can see they have a sort of syntax for adding items like the file name, so you can write code that detects a new error, and adds the info you care about to the error.source field in the format that their dialog boxes understand. I use the General Error Handler to clear the one error I am expecting. If I don't want a popup in the case of other errors, I test whether code=mycode first. So you are basically saying that I should write a wrapper for each file function so that errors are properly handled? Argh, my neck hurts already, in anticipation of the pain. I was hoping to just use the better file functions and avoid the worse. Quote Link to comment
Rolf Kalbermatter Posted February 17, 2009 Report Share Posted February 17, 2009 QUOTE (torekp @ Feb 16 2009, 07:48 AM) I use the General Error Handler to clear the one error I am expecting. If I don't want a popup in the case of other errors, I test whether code=mycode first.So you are basically saying that I should write a wrapper for each file function so that errors are properly handled? Argh, my neck hurts already, in anticipation of the pain. I was hoping to just use the better file functions and avoid the worse. The only problem where you should get a not file found error is in fact when trying to open a file. So I do not see how you would have to wrap all FileIO functions. Just creating your own Create File/Open File function and using them consistently in your apps would help. Rolf Kalbermatter Quote Link to comment
torekp Posted February 18, 2009 Author Report Share Posted February 18, 2009 QUOTE (rolfk @ Feb 16 2009, 02:48 PM) The only problem where you should get a not file found error is in fact when trying to open a file. So I do not see how you would have to wrap all FileIO functions. Just creating your own Create File/Open File function and using them consistently in your apps would help. OK not ALL file functions, just half. The reading half. Read spreadsheet file, read tdms file, read binary file, etc. (I speak loosely - some of these include the opening of the file, some require a separate opening action, but you get the point.) Quote Link to comment
jdunham Posted February 18, 2009 Report Share Posted February 18, 2009 QUOTE (torekp @ Feb 16 2009, 04:48 AM) I use the General Error Handler to clear the one error I am expecting. If I don't want a popup in the case of other errors, I test whether code=mycode first. Well that works, but the error exception part of it should just be a separate VI. I find that I don't want to clear errors in the same place as I want to tell the user about errors. And then the Clear Errors.vi clears all errors which I feel is dangerous because the code will silently suppress any errors, not just the ones you anticipate. It's all fixable with your own code, I just think NI should improve the API so everyone uses the same stuff instead of rolling their own. QUOTE (torekp @ Feb 17 2009, 09:59 AM) OK not ALL file functions, just half. The reading half. Read spreadsheet file, read tdms file, read binary file, etc. (I speak loosely - some of these include the opening of the file, some require a separate opening action, but you get the point.) Well a lot of the new functions already have the functionality you crave (they include the file name in the error message). Quote Link to comment
torekp Posted February 20, 2009 Author Report Share Posted February 20, 2009 OK, I found out that my problems come mainly from Read From Spreadsheet File (possibly, also, Open TDMS File). So to replace Read From Spreadsheet, I used a Moore Good Ideas freeware VI, called Read Entire File.vi, which has better error messages. I then added this: and then made versions for DBL, SGL, i32, and i64, and polymorphed 'em. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.