If an error is thrown inside a node.js function that handles incoming messages from RabbitMQ, the stack trace is from the node-amqp code instead of the one in my handler (and the error is commonly "cannot call method indexOf of undefined", regardless of what the actual error is).
Is there any way to get a stacktrace of my code being executed instead of one that stops at "the edge" of the node-amqp module?
Example stack trace:
stackTrace=TypeError: Cannot call method 'indexOf' of undefined
at Queue._onMethod (/myproject/node_modules/besedoq/node_modules/amqp/lib/queue.js:398:23)
at Queue.Channel._onChannelMethod (/myproject/node_modules/besedoq/node_modules/amqp/lib/channel.js:85:12)
at Connection._onMethod (/myproject/node_modules/besedoq/node_modules/amqp/lib/connection.js:443:28)
at AMQPParser.self.parser.onMethod (/myproject/node_modules/besedoq/node_modules/amqp/lib/connection.js:136:12)
In the lib at the line your stack trace refers to seems to lack a name of the queue, if you give your queue a name - maybe you get better stack trace?
https://github.com/postwait/node-amqp/blob/master/lib/queue.js#L398
Related
So I am writing a test framework with jest-playwright.
One of the things I have not been able to work out is how to get a full strack trace of my errors
This is my framework
I have a file called testapp.ts which contains all the methods to drive the tests eg navigation, login, clicking buttons etc
Then I have test suites eg test1.test.ts this will have tests in it, the tests will then call what methods are required in testapp.ts to drive the test
Now within my methods there will be verification points, my problem is when the verification fails and an error is thrown, it will only show me the line number in the method that failed
What I want is for full stack trace to be shown eg
test1.test.ts > line number of test which calls the method in testapp.ts, and then
testapp.ts > line number of method where verification fails
this is simplifying it and you would think it should be easy to trace without this but in my framework I will have lots of tests calling methods.. those methods will call other methods and somewhere in that path the error will be thrown so I need to be able to follow the path
my methods and tests are all async and my method calls are await I believe that is the reason its happening
however the same tests if using playwright/test stack trace properly so why cant jest? Also same for java with selenium you get the full stack trace
Thanks
I have logger.js file, and I import logger from it.
Then I do logger.info(Console.trace());
Console.Trace already works, but I need to log it- However, this results in an error saying "arguments of type void is not assignable to type "object"
What am I doing wrong here?
Console.trace() outputs the stack trace to stderr, so you can't exactly capture it. Typically the correct way to get a stack trace is to get it with a new Error() object.
let err = new Error("Error Message")
logger.log("error", "Exception Dump", err)
In the above example, there's a few things going on here. When we call the new Error() it captures a stack trace for us. Then on the logger call, we're using the .log() method. This allow us to declare the log level, provide a message, and then an object that is handled by util.inspect() in the resulting log entry.
Oi
I have a bpel process that puts messages in a jms queue and I need to do some specific work if the insertion on the queue fails for some reason.
To test that i disabled the insertion on the EM console but when the bpel tries to insert an exception is raised and i can't catch it.
Any work around for my problem?
This is my response
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header>
<tracking:faultId xmlns:tracking="http://oracle.soa.tracking.core.TrackingProperty">470018</tracking:faultId>
</env:Header>
<env:Body>
<env:Fault>
<faultcode>env:Server</faultcode>
<faultstring>Exception occurred when binding was invoked. Exception occurred during invocation of JCA binding: "JCA Binding execute of Reference operation 'Produce_Message' failed due to: ERRJMS_PROVIDER_ERR. ERRJMS_PROVIDER_ERR. Unable to produce message due to JMS provider internal error. Please examine the log file to determine the problem. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution.</faultstring>
<faultactor/>
<detail>
<exception>Failed to send message to the destination SRVMEModule!SRVS04: Destination is suspended</exception>
</detail>
</env:Fault>
</env:Body>
</env:Envelope>
Your fault looks like a standard binding fault which could be easly caught and handled. Put your jms insert activity inside a scope and you should be able to define error handler(catch all) on the scope level.
We're using FFI to call potentially unsafe C functions. Sometimes bugs in such functions made our Haskell code that is using them to popup "Segmentation fault/access violation in generated code" message in the console. Under Windows I cannot do anything with that. I cannot see the source of the problem.
Is there a way to disable that message so the unhandled exception propagate to the OS, so we could catch it and see which C-compiled DLL on the call chain gives the error and where there?
We have a number of sections of code in the format:
try
{
// code
}
catch(std::exception &e)
{
// log exception
}
catch(...)
{
// log unknown exception.
}
Every so often, the unknown exception code triggers, and logs an unknown exception.
I always thought that all exceptions were meant to derive from std::exception, and thus catching std::exception would catch all exceptions.
Is there some other exception that I should be catching?
If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
edit
We managed to locate the cause of the problem- despite saying that they had, the customer had not installed .NET 3.5, which our code depends on, and the system fell over when trying to use the XML parser.
Is there some other exception that I should be catching?
This depends on your code. Libraries you call can throw exceptions not derived from std::exception, examples are MFC's CException or Microsoft's _com_error. Also, an access violation might be catched by catch(...), which is the reason why I would not use catch(...) in my code - it's just to broad for me.
2.If my code ends up in the unknown exception handler, is there any way that I can find out what exception was actually caught?
You can run your code in the debugger and configure the debugger to break your program when the exception is thrown (first chance). Then you know exactly which line of code triggers the exception and should be able to see what exactly is thrown.