IBM OS400 C ILE program
Does anyone know when MCH1206 is issued in a C program? The C program does not have any error handling defined.
In my environment, whenever there is an overflow, - e.g. result = pow(a,b)
If there is an overflow, result is set to HUGE_VAL, and it continues execution. In the joblog, i can see this message:
"Floating-point overflow exception occurred in CEESDXPD."
However, in another environment, it stops execution and issuing this message
"Floating point overflow condition detected.
Application error. MCH1206 unmonitored by F07RTB at statement 00000038,"
Is there are global handling (e.g. defined in the system level)? Global handling for maths library?
Thanks
Related
I always want to know reason behind the exception - asyncio.CancelledError
I am using this for pyVim.connect.SmartConnect, but it gives exception asyncio.CancelledError for:
1.Wrong username/password
2.Host other than vcenter
I just want to know whether exception occurred for case 1 or case 2, Is there any such way??
We have 2 applications, the first one is VCL project, the other is a windows service.
In the VCL project we do:
try
except
on E: Exception do
// do something with E.Message
end
but in the windows service (which uses several threads) we use:
try
except
// do something with Exception(ExceptObject).Message
end
The information I got from my coworkers is that "We must use ExceptObject in threads and E: Exception in applications that use GUI". But I couldn't find anything regarding this.
I found an example here http://edn.embarcadero.com/article/10452 where it uses an instance variable to store the exception and it uses the ExceptObject, but gives no explanation why.
Is this ExceptObject even thread-safe (since it comes from the unit 'System')?
So what is the right way to handle exceptions in Delphi and why is there more than one way to do it?
There is no right way for exception handling. There is just one way. What might confuse you could be dealing with the exception object which is created, and which causes an exception to raise, but whose lifetime is the most important for you here.
In general, there's only two ways of dealing with those exception objects. Either you let them alive beyond the exception block scope and release them by yourself or let them free by the RTL when the exception block ends.
But to answer what I guess you've asked. Exception class isn't thread safe. And, your coworkers were wrong as no one is forced to use specific exception handling in threads. These rules are the same for all threads created by the process, no matter what. Just, those exception objects can be unstable within exception blocks:
1. Get the current exception object from the ExceptObject
The ExceptObject returns the current exception object. In practice, it may cause this; if you store such object reference into a variable inside an exception handler block and another exception will get raised within such block, that stored instance may become invalid. Which is quite unsafe.
But it doesn't mean you could not take a reference of such object and pass it to another thread by using some synchronization mechanisms (since it's not a thread safe class) and work with it there. You just need to take care that no other exception will be raised because that would invalidate the previously stored object so as you must take care of staying inside the exception handler from the caller's point of view and you must use a kind of thread synchronization mechanism.
So actually working with the exception object acquired from an on expression can be more stable than using ExceptObject. But the same rules applies here as well; you'd need to synchronize the object instance from the on expression with another thread (since it's not a thread safe class), but in such case, object acquired from the on expression won't get changed unlike the ExceptObject one can be within a certain exception block.
2. Retain exception object by using AcquireExceptionObject
The AcquireExceptionObject function allows you to keep the exception object alive even out of the exception block.
For an exception handling when speaking about thread synchronization, I'd suggest you using the AcquireExceptionObject function which makes the exception object free to consume, even after the exception block ends. For you that brings the only responsability, free such acquired object by calling the ReleaseExceptionObject procedure or raising the exception by this object again.
Victoria is absolutely correct.
Personally, I have a strong preference for this idiom:
try
...
except
// IO error
On E : EInOutError do
ShowMessage('IO error : '+E.Message);
// Division by zero
On E : EDivByZero do
ShowMessage('Div by zero error : '+E.Message);
// Catch other errors
else
ShowMessage('Unknown error');
end;
To elaborate:
Victoria said "There is no right way for exception handling. There is just one way." That's absolutely correct.
The advice you got about "use one syntax for threads, and the other for GUIs" is simply wrong. There is no "different syntax" for "threads" vs. "GUI". That's nonsense :(
I prefer using on : MyExceptionType in an exception block.
I also prefer to differentiate different exception types, whenever/wherever possible.
The example you cited, http://edn.embarcadero.com/article/10452, deals with how to avoid a possible access violation if you don't handle the exception within that particular thread. Saving the exception instance in a member variable helps mitigate this problem.
The following link might help clarify:
http://www.delphibasics.co.uk/Article.asp?Name=Exceptions
In node.js applications i saw usage of both these methods process.exit(1) and process.exit(0). Can anybody give me the exact answer ?
Node normally exits with a 0 status code when no more async operations
are pending. There are other exit codes which are described below:
1 - Uncaught Fatal Exception: There was an uncaught exception, and it was not handled by a domain or an uncaughtException event handler.
2 - Unused: Reserved by Bash for built in misuse.
3 - Internal JavaScript Parse Error: The JavaScript source code internal in Node's bootstrapping process caused a parse error. This is
extremely rare, and generally can only happen during the development
of Node itself.
4 - Internal JavaScript Evaluation Failure: The JavaScript source code internal in Node's bootstrapping process failed to return a
function value when evaluated. This is extremely rare, and generally
can only happen during the development of Node itself.
5 - Fatal Error: There was a fatal unrecoverable error in V8. Typically, a message will be printed to stderr with the prefix FATAL
ERROR.
6 - Non-function Internal Exception Handler: There was an uncaught exception, but the internal fatal exception handler function was
somehow set to a non-function, and could not be called.
7 - Internal Exception Handler Run-Time Failure: There was an uncaught exception, and the internal fatal exception handler function
itself threw an error while attempting to handle it.
8 - Unused
9 - Invalid Argument: Either an unknown option was specified, or an option requiring a value was provided without a value.
10 - Internal JavaScript Run-Time Failure: The JavaScript source code internal in Node's bootstrapping process threw an error when the
bootstrapping function was called. This is extremely rare, and
generally can only happen during the development of Node itself.
11 - Invalid Debug Argument: The --debug and/or --debug-brk options were set, but an invalid port number was chosen
>128 - Signal Exits: If Node receives a fatal signal such as SIGKILL or SIGHUP, then its exit code will be 128 plus the value
of the signal code. This is a standard Unix practice, since exit codes
are defined to be 7-bit integers, and signal exits set the high-order
bit, and then contain the value of the signal code.
Source: https://www.tutorialspoint.com/nodejs/nodejs_process.htm
You can find the answer to your question in the documentation: https://nodejs.org/api/process.html#process_process_exit_code
Basically if you want to exit with success use 0 if you want to exit with failure use 1.
0 is a success code and 1 (or another number) can be a failure code. 0 will be used if nothing is specified. Useful for passing information on the way out. Answered on SO here:
https://stackoverflow.com/a/5266239/5463636
More info direct from the Node.js docs here:
https://nodejs.org/api/process.html#process_process_exit_code
I do hundreds of request per second using the request module in nodejs and sometimes i get the following error
nodejs: ../deps/uv/src/unix/async.c:149: uv__async_io: Assertion `n == sizeof(val)' failed.
Code: null Signal: SIGABRT
how can i catch the signal?
An assert is blowing up, and that particular one is there to catch programming errors, or totally unexpected conditions. Another user reported this to us, but it turned out it was a missuse of the API. I suggest you open an issue on our bugtracker: https://github.com/libuv/libuv/issues, ideally with a reproducible reduced test case.
I'm currently trying to wrap my mind around the correct way to use exceptions in Haskell. How exceptions work is straight-forward enough; I'm trying to get a clear picture of the correct way to interpret them.
The basic position is that, in a well-designed application, exceptions shouldn't escape to the top-level. Any exception that does is clearly one which the designer did not anticipate - i.e., a program bug (e.g., divide by zero), rather than an unusual run-time occurrence (e.g., file not found).
To that end, I wrote a simple top-level exception handler that catches all exceptions and prints a message to stderr saying "this is a bug" (before rethrowing the exception to terminate the program).
However, suppose the user presses Ctrl+C. This causes an exception to be thrown. Clearly this is not any kind of program bug. However, failing to anticipate and react to a user abort such as this could be considered a bug. So perhaps the program should catch this and handle it appropriately, doing any necessary cleanup before exiting.
The thing is, though... The code that handles this is going to catch the exception, release any resources or whatever, and then rethrow the exception! So if the exception makes it to the top-level, that doesn't necessarily mean it was unhandled. It just means we wanted to exit quickly.
So, my question: Should exceptions be used for flow-control in this manner? Should every function that explicitly catches UserInterrupt use explicit flow-control constructs to exit manually rather than rethrow the exception? (But then how does the caller know to also exit?) Is it OK for UserInterrupt to reach the top-level? But in that case, is it OK for ThreadKilled too, by the same argument?
In short, should the interrupt handler make a special case for UserInterrupt (and possibly ThreadKilled)? What about a HeapOverflow or StackOverflow? Is that a bug? Or is that "circumstance beyond the program's control"?
Cleaning up in the presence of exceptions
However, failing to anticipate and react to a user abort such as this could be considered a bug. So perhaps the program should catch this and handle it appropriately, doing any necessary cleanup before exiting.
In some sense you are right — the programmer should anticipate exceptions. But not by catching them. Instead, you should use exception-safe functions, such as bracket.
For example:
import Control.Exception
data Resource
acquireResource :: IO Resource
releaseResource :: Resource -> IO ()
workWithResource = bracket acquireResource releaseResource $ \resource -> ...
This way the resources will be cleaned up regardless of whether the program will be aborted by Ctrl+C.
Should exceptions reach top level?
Now, I'd like to address another statement of yours:
The basic position is that, in a well-designed application, exceptions shouldn't escape to the top-level.
I would argue that, in a well-designed application, exceptions are a perfectly fine way to abort. If there are any problems with this, then you're doing something wrong (e.g. want to execute a cleanup action at the end of main — but that should be done in bracket!).
Here's what I often do in my programs:
Define a data type that represents any possible error — anything that might go wrong. Some of them often wrap other exceptions.
data ProgramError
= InputFileNotFound FilePath IOException
| ParseError FilePath String
| ...
Define how to print errors in a user-friendly way:
instance Show ProgramError where
show (InputFileNotFound path e) = printf "File '%s' could not be read: %s" path (show e)
...
Declare the type as an exception:
instance Exception ProgramError
Throw these exceptions in the program whenever I feel like it.
Should I catch exceptions?
Exceptions that you anticipate must be caught and wrapped (e.g. in InputFileNotFound) to give them more context. What about the exceptions that you don't anticipate?
I can see some value in printing "it's a bug" to the users, so that they report the problem back to you. If you do this, you should anticipate UserInterrupt — it's not a bug, as you say. How you should treat ThreadKilled depends on your application — literally, whether you anticipate it!
This, however, is orthogonal to the "good design" and depends more on what kind of users you're targeting, what you expect of them and what they expect of your program.
The response may range from just printing the exception to a dialog that says "we're very sorry, would you like to submit a report to the developers?".
Should exceptions be used for flow-control in this manner?
Yes. I highly recommend you read Breaking from a loop, which shows how Either and EitherT at their core at nothing more than abstractions for exiting from a code block early. Exceptions are just a special case of this behavior where you exit because of an error, but there is no reason why that should be the only case in which you exit prematurely.