I would like to exit the validation if a phase fails (the idea is phase 1 invocation mismatch checking, phase 2 content checking.
I can structure my testing in phases but how do I get Schematron to exit gracefully rather than going to the next phase?
Peter
Related
Outside of logging the failure to stderr and a log file, how should I deal with a fatal error?
example:
VkResult result = vkCreateInstance(&createInfo, NULL, &vulkanInfo->instance);
if (result != VK_SUCCESS) {
// ???
}
If vkCreateInstance fails, it's all over. The app cannot continue. What should I do?
Targets are Windows, Mac, Linux, Switch, and more.
I realize this is a very open ended question. I’m just curious how the great minds here deal with it.
how should I deal with a fatal error?
The app cannot continue
Because The app cannot continue you should stop your application. A properly written application would:
print an error message to stderr
stop and join and synchronize all threads
free all dynamically allocated memory
close all open files
generally clean up all shared resources if needed (I think of shared memory)
exit the application with an error
To be (almost extremely unnecessarily) portable, you can use exit(EXIT_FAILURE) to notify the system that your application exited with an error (but better use exit(EXIT_FAILURE) for readability). For the platforms you target, use exit() with any other value than 0 - exit(0) means application succeeded. For many applications, some specific exit values are also used to notify the upper application of what specific error happened, like grep exits 0 if it filtered some lines, 1 if no lines were filtered, and other exit codes if an error occurred (like for example the file does not exist).
Best cross platform practices for dealing with a fatal error in C?
Your code is dealing with Vulkan, so it's reasonable to assume that almost everyone using your software will be using a GUI and will not look at (and never see) anything sent to stdout or stderr. Instead; they will expect a "GUI specific notification" (a dialog box).
There's multiple different "cross platform GUI toolkit" libraries online to choose from (if you don't feel like writing a minimal wrapper for a dialog box and nothing else).
So a bit of context, i was trying to make a code which reads in the number of jobs and then the jobs themselves goes something like this
4
1
2
3
4
Heres the thing
if i enter the number of jobs as 4
then enter 3 jobs,
then for some reason it reads in the third job again .
is there any way to check and raise an error if this happens? i would compare two values to check if they were the same, but two values can be same.
also
i would be using a file lets say file.txt
file.txt would have the number of jobs and jobs in the format
4
1
2
3
4
and i would use ./mx3 < file.txt
where mx3 is the program compiled using gcc c99
Can you post some code for better understanding ?
I didn't understand your problem at all but i think that could help you :
Return Value of scanf
: copy and past from here
These functions return the number of input items successfully matched and assigned, which can be fewer than provided for, or even zero in the event of an early matching failure.
The value EOF is returned if the end of input is reached before either the first successful conversion or a matching failure occurs. EOF is also returned if a read error occurs, in which case the error indicator for the stream (see ferror(3)) is set, and errno is set indicate the error.
(I'm new on stack forgive me if i'm clumsy and explain me if possible for my self improvement ^^)
Is it a requirement to call sqlite3_reset() on a prepared statement after a failed call to sqlite3_step()? I'm using sqlite3 version 3.23.1. The lifecycle of my prepared statements is as follows:
At the start of my application, I globally do sqlite3_prepare_v2() and keep the handle to the prepared statement available for the lifetime of the application.
When I'm ready to do a query, I invoke one of the sqlite3_bind_*() functions, then do sqlite3_step() on that statement until I get something other than SQLITE_ROW returned.
Then the code below is executed to reset the statement.
Here is the part of the code that happens after I call sqlite3_step(). Note that variable resultCode holds the return value of the last call to sqlite3_step().
if (resultCode == SQLITE_DONE || resultCode == SQLITE_ROW)
{
if (sqlite3_reset(m_statement) != SQLITE_OK)
{
LogDbFailure(*m_db, "sqlite3_reset()");
}
}
else
{
LogDbFailure(*m_db, "sqlite3_step()");
success = false;
}
Notice that if the call to step failed, I don't do a reset. Nothing in the documentation or search results on Google indicate that sqlite3_reset() must be called on failures. In fact, the documentation states that calling sqlite3_reset() after a failure will also fail:
If the most recent call to sqlite3_step(S) for the prepared statement S indicated an error, then sqlite3_reset(S) returns an appropriate error code.
Reading this made me think that maybe I shouldn't call the reset function if step fails.
Can anyone clarify? Note in my case, sqlite3_step() is failing because of SQLITE_BUSY. I am using WAL journalling mode. Once step fails on a prepared statement, that prepared statement is forever in busy state when I call sqlite3_step(). Calls to sqlite3_bind_*() after that return sqlite3_bind_int64() failed (21): bad parameter or other API misuse (log format is my own, but 21 is the error code), which makes me think that reset should be called in failure cases, since all errors seem to indicate that the database is busy because of the prepared statement stuck in mid-transaction due to the lack of a reset.
Notice that if the call to step failed, I don't do a reset. Nothing in
the documentation or search results on Google indicate that
sqlite3_reset() must be called on failures.
Well no, not specifically, but the docs for sqlite3_reset() do say
The sqlite3_reset() function is called to reset a prepared statement
object back to its initial state, ready to be re-executed.
You add,
In fact, the documentation
states that calling sqlite3_reset() after a failure will also fail:
If the most recent call to sqlite3_step(S) for the prepared statement S indicated an error, then sqlite3_reset(S) returns an
appropriate error code.
No, you are misinterpreting that. There is an important distinction between "returns an appropriate error code" and "will fail". That should be clearer when considered in the context of this excerpt from the docs for sqlite3_step():
In the legacy interface, the sqlite3_step() API always returns a
generic error code, SQLITE_ERROR, following any error other than
SQLITE_BUSY and SQLITE_MISUSE. You must call sqlite3_reset() or
sqlite3_finalize() in order to find one of the specific error codes
that better describes the error.
Although that behavior of sqlite3_step() applies only to the legacy interface, not the V2 interface, it explains why the return value of sqlite3_reset() reports on the result of previous calls (if any) to sqlite3_step(), not on its own success or failure. It is implicit that the reset itself cannot fail, or at least cannot report on its own failure via its return code.
Reading this made me think that maybe I shouldn't call the reset
function if step fails.
The docs for sqlite3_step() have this to say on that point:
For all versions of SQLite up to and including 3.6.23.1, a call to
sqlite3_reset() was required after sqlite3_step() returned anything
other than SQLITE_ROW before any subsequent invocation of
sqlite3_step().
Note: it is therefore not wrong to call sqlite3_reset() after sqlite3_step() reports an error. The docs go on to say,
Failure to reset the prepared statement using
sqlite3_reset() would result in an SQLITE_MISUSE return from
sqlite3_step(). But after version 3.6.23.1 (2010-03-26, sqlite3_step()
began calling sqlite3_reset() automatically in this circumstance
rather than returning SQLITE_MISUSE.
That seems inconsistent with the behavior you report, but note that,
[...] The SQLITE_OMIT_AUTORESET
compile-time option can be used to restore the legacy behavior.
Thus, your safest bet is to reset the statement unconditionally, rather than to avoid resetting it after an error is reported. That might be unnecessary with many SQLite3 builds, but it is not wrong or harmful, and it is necessary with some builds.
I am currently (don't ask why :P) implementing my own versions of malloc() and free(), and have intentionally placed an assert(0) at the first line of free() for current debugging purposes.
A driver program is testing a random sequence of these malloc() and free() to test the correctness of my implementations.
When I run the driver, however, the shell prints out that "Assertion '0' failed", keeps running for a little bit longer, and then prints "Aborted". Actually, it looks like it is able to even call malloc() several times between reporting the failure of the assertion and then finally reporting that the program has aborted. I am sure of this because of certain printf statements I have placed in the code to print out certain variables for debugging purposes.
I am not asking for any help at all about implementing malloc() and free(). Would just like to know what is means when it seems that the program continues to run for a short time (even possibly calling other user-defined functions) even after an assertion has been reported to fail.
If you're seeing 'assertion failed', followed by debugging prints, followed by an exit, there are two obvious possibilities.
One is that the assertion message and the debugging prints are going into two different buffered output streams (e.g. stderr and stdout) that are not getting flushed in the same order they are filled.
Another is that multiple threads of execution are hitting malloc().
If you're on a glibc-based system, the issue is probably that fprintf calls malloc internally, and assert in turn uses fprintf to print the assertion failure message. This of course is a very bad design, as printing error messages from out-of-memory conditions will always fail (among many other problems), but that's how it is...
According to the docs, fprintf can fail and will return a negative number on failure. There are clearly many situations where it would be useful to check this value.
However, I usually use fprintf to print error messages to stderr. My code will usually look something like this:
rc = foo();
if(rc) {
fprintf(stderr, "An error occured\n");
//Sometimes stuff will need to be cleaned up here
return 1;
}
In these cases, is it still possible for fprintf to fail? If so, is there anything that can be done to display the error message somehow or is there is a more reliable alternative to fprintf?
If not, is there any need to check fprintf when it is used in this way?
The C standard says that the file streams stdin, stdout, and stderr shall be connected somewhere, but they don't specify where, of course.
(C11 §7.21.3 Files ¶7:
At program startup, three text streams are predefined and need not be opened explicitly -- standard input (for reading conventional input), standard output (for writing conventional output), and standard error (for writing diagnostic output). As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.
It is perfectly feasible to run a program with the standard streams redirected:
some_program_of_yours >/dev/null 2>&1 </dev/null
Your writes will succeed - but the information won't go anywhere. A more brutal way of running your program is:
some_program_of_yours >&- 2>&- </dev/null
This time, it has been run without open file streams for stdout and stderr — in contravention of the the standard. It is still reading from /dev/null in the example, which means it doesn't get any useful data input from stdin.
Many a program doesn't bother to check that the standard I/O channels are open. Many a program doesn't bother to check that the error message was successfully written. Devising a suitable fallback as outline by Tim Post and whitey04 isn't always worth the effort. If you run the ls command with its outputs suppressed, it will simply do what it can and exits with a non-zero status:
$ ls; echo $?
gls
0
$ ls >&- 2>&-; echo $?
2
$
(Tested RHEL Linux.) There really isn't a need for it to do more. On the other hand, if your program is supposed to run in the background and write to a log file, it probably won't write much to stderr, unless it fails to open the log file (or spots an error on the log file).
Note that if you fall back on syslog(3) (or POSIX), you have no way of knowing whether your calls were 'successful' or not; the syslog functions all return no status information. You just have to assume that they were successful. It is your last resort, therefore.
Typically, you'd employ some kind of logging system that could (try) to handle this for you, or you'll need to duplicate that logic in every area of your code that prints to standard error and exits.
You have some options:
If fprintf fails, try syslog.
If both fail, try creating a 'crash.{pid}.log' file that contains information that you'd want in a bug report. Check for the existence of these files when you start up, as they can tell your program that it crashed previously.
Let net connected users check a configuration option that allows your program to submit an error report.
Incidentally, open() read() and write() are good friends to have when the fprintf family of functions aren't working.
As whitey04 says, sometimes you just have to give up and do your best to not melt down with fireworks going off. But do try to isolate that kind of logic into a small library.
For instance:
best_effort_logger(LOG_CRIT, "Heap corruption likely, bailing out!");
Is much cleaner than a series of if else else if every place things could possibly go wrong.
You could put the error on stdout or somewhere else... At some point you just have to give error reporting a best effort and then give up.
The key is that your app "gracefully" handles it (e.g. the OS doesn't have to kill it for being bad and it tells you why it exited [if it can]).
Yes, of course fprintf to stderr can fail. For instance stderr could be an ordinary file and the disk could run out of space, or it could be a pipe that gets closed by the reader, etc.
Whether you should check an operation for failure depends largely on whether you could achieve better program behavior by checking. In your case, the only conceivable things you could do on failure to print the error message are try to print another one (which will almost surely also fail) or exit the program (which is probably worse than failing to report an error, but perhaps not always).
Some programs that really want to log error messages will set up an alternate stack at program start-up to reserve some amount of memory (see sigaltstack(2) that can be used by a signal handler (usually SIGSEGV) to report errors. Depending upon the importance of logging your error, you could investigate using alternate stacks to pre-allocate some chunk of memory. It might not be worth it :) but sometimes you'd give anything for some hint of what happened.