# Open user's template file
if [catch { set f_id [open "$ex_doc_template_file" r] } res] {
# Close output file before abort
global html_output_file_id
catch { close $html_output_file_id }
MOM_abort "$ex_doc_template_file can not be open!"
}
I have the above code which need to open a template file, few days ago still working, yesterday just start showing can not be open, could help what is the problem on it?
The error message will be in the res variable. That should tell you what is wrong; add it to the abort message, perhaps like this:
MOM_abort "$ex_doc_template_file can not be open! $res"
Then you'll find that it is probably something obvious.
In general, when handling failures by reporting something, it's very useful to report the actual failure message as that often says what the problem is. I find that Tcl's messages are useful, at least for the immediate error. (The higher-level reasons why can take thought, of course.)
Related
Is there a way in C++ to tell if std::cout and std::cerr are pointing to the same destination?
That is, I'd like to be able to distinguish when the program is launched like
program or program > log 2>&1 or program &> log
versus
program > log or program 2> errors or program > log 2> errors
(The use case is a situation where we'd like error information to be printed to both stdout and stderr when they are separate, but want to print a slightly differently formatted output (not just a concatenation) if they both go to the same destination. -- Yes, I'm aware this isn't ideal, and isn't the officially recommended way to do things, and shouldn't be looked on as a standard way of doing things. But please just trust me, though, that we've taken time to think things through, and for our particular use case this is the best option.)
For our purposes, we can assume that nothing has been done with cout/cerr redirection within the program itself (just the typical shell-level command line redirection), so if there's C-level functionality which looks at stdout/stderr directly (rather than the std::cout and std::cerr streams proper), that would likely work too.
This is another case of the XY Problem.
What you are really trying to accomplish is:
For our end-user use cases, we want to be sure that messages indicating what error has occurred end up in both stderr and stdout (because depending on how our users have or have not set up output redirection they may or may not see it in one or the other.) We could just print things once to each (effectively what we're doing currently), but if stdout and stderr go to the same location, it would be clearer and more user friendly if we could reformat things to remove the redundant printing.
Given that objective, a cleaner mechanism would be to allow the user to specify where they would like the error messages to go to. E.g.
the-program --error-destination "stdout"
the-program --error-destination "stderr"
the-program --error-destination "stdout,stderr"
the-program --error-destination "/tmp/errro-messages.txt"
the-program --error-destination "stdout,/tmp/errro-messages.txt"
With the understanding that "stdout" and "stderr" are special destinations. Anything else is a file.
If you really want to know on linux, /proc/self/fd will reveal all! Try ls -l /proc/self/fd today...
Also, if you really want to emit an error to the console, having determined the redirects have stolen your output, then you could always send it to /dev/tty. Don't bother with /dev/stderr as that is just a link to /proc/self/fd/2! The one issue with this is if your program is detached from the console with hup or similar then you can't use /dev/tty obviously.
When I try to use the function uv_close((uv_handle_t*)client,NULL) in libuv library to actively close the TCP connection with the client, the error
"main: src/unix/core.c:117: uv_close: Assertion `!uv__is_closing(handle)' failed."
was reported. I search a lot online, but I still cannot find the correct way to solve the problem. I wish someone can tell me why this problem resulted and how to solve it.
You are trying to close a handle that is either already closed or in a closing state (that is, somewhere along the process that brings the handle from being alive to being closed).
As you can see from the code of libuv, the uv_close function starts as:
void uv_close(uv_handle_t* handle, uv_close_cb close_cb) {
assert(!uv__is_closing(handle));
handle->flags |= UV_CLOSING;
// ...
Where uv__is_closing is defined as:
#define uv__is_closing(h) \
(((h)->flags & (UV_CLOSING | UV_CLOSED)) != 0)
To sum up, as soon as uv_close is invoked on a handle, the UV_CLOSING flag is set and it's checked on subsequent calls to avoid multiple runs of the close function. In other terms, you can close a handle only once.
The error comes out because you are probably invoking uv_close more than once for a handle. However, it's hard to say without looking at the real code.
As a side note, you can use uv_is_closing to test your handle if you are in doubt. It's a kind of alias for uv__is_closing.
It's just plain luck my program is so simple, so I eventually found out what causes the mysterious log message. My program log looks like this:
Debugging starts
failed to start
Debugging has finished
Which happens after:
camera = new QCamera(QCameraInfo::defaultCamera());
// see http://omg-it.works/how-to-grab-video-frames-directly-from-qcamera/
camera->setViewfinder(frameGrabber = new CameraFrameGrabber());
camera->start();
The start() method causes this message in console. Now the meaning of the message is obvious, what it's not very helpful. What steps should I take to troubleshoot it?
Reasons for this might differ, but in my case it was simply because I provided invalid QCameraInfo. The culprit is that QCameraInfo::defaultCamera() might return invalid value if Qt fails to detect any cameras on your system, which unfortunately happens even if cameras are present.
What is the best way to flex and bison to stop processing when an error is encountered. If I call yyerror, it does not stop scanning and parsing my file. While the input is syntactically correct, there is an user error, such as they tried to load the same file twice. Once I am out of flex/bison, then my program will return an error to the user and the program should keep running. I assume that throwing a C++ exception would probably break something?
YYABORT is the standard way of getting out; it causes yyparse to return immediately with a failure (1). You can then throw an exception or do whatever you want. You'll need to reset flex's input if you want to parse something else, but if you do, you can just call yyparse again and parsing will start over from the beginning.
YYACCEPT stop parse and return 0.
I am having a strange problem in my code. I have many asserts scattered around the code and all have been working fine. Whenever an assert failed I got a message giving me line number of where the failure happened.
Today I wrote another assert in a function which loads a file. Just wanted to make sure that the fie existed. A very simple assert. Here is the relevant code:
//Check that the file exists and can be opened
FILE* f = fopen(filename, "rb");
#ifdef ASSERTIONS_ON
assert(f!=NULL);//#problem For some reason while all other asserts work, this one just crashes the program without reporting line
#else
if(f == NULL)
return MODEL_LOAD_FILENOTFOUND;
#endif
fclose(f);
I know that this does not help a lot but just wanted to showcase what my problem is. My OS is Windows 7. The compiler is GCC. The error message I get from Windows is the usual runtime error but without line reporting:
"The application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information"
What could be the problem? What can possibly cause an assert failure to just request termination without reporting a line where it happens, while in every other case in the same code it works as intended? Thanks in advance for any assistance!
You most likely have FUBAR'ed the stack somewhere before the assert executes.