I am using the Bloomberg API and getting this error in VS. Its not crashing the program but I see the errors in the output window. I just want to make sure things are running smoothly and I'm concerned there is something wrong. Does anyone know what this is or how I can get more details about it?
switch (eventObj.Type)
{
case Event.EventType.SUBSCRIPTION_DATA:
Debug.WriteLine("");
Debug.WriteLine("hit subscription DATA");
foreach (Message msg in eventObj.GetMessages())
{
}
}
this error
Exception thrown: 'System.IO.IOException' in Bloomberglp.Blpapi.dll
gets produced on the for-each message in my code. How can I see details on this so I can fix the issue?
I'm summarizing the information from the extensive comment discussion for future readers:
Make sure you're only iterating over messages of events that are of type SUBSCRIPTION_DATA, you should change your code to check the type of the event before handling it:
Event eventObj = session.NextEvent();
switch (eventObj.Type)
{
case Event.EventType.SUBSCRIPTION_DATA:
foreach (Message msg in eventObj.GetMessages())
{ ... }
break;
default:
HandleOtherEvent(eventObj);
break;
}
To get VS to halt on any exception in any thread, check everything in "Exception Settings" (ctrl+alt+E)
You can correlate a subscription event with a subscription using the correlation ID. Check which correlation ID the event has when VS halts on an exception then find out which security the subscription is on, create a sample test and discuss with Bloomberg's HELP HELP.
Per comments below, OP has discussed with HELP HELP that told him/her that this is a Bloomberg issue that has been resolved in the latest API library. Installing the latest library has fixed the issue.
Related
I want to submit a score to my leaderboard. Sometimes it works but sometimes i get the error:
Error Code 6: STATUS_NETWORK_ERROR_OPERATION_FAILED
I am connected to the internet and enabled multiplayer in the developer console. Any ideas?
Here is my code:
MainActivity:
if(isSignedIn()){
Games.Leaderboards.submitScoreImmediate(mGoogleApiClient, this.leaderboardId,
targetScore).setResultCallback(new LeaderBoardSubmitScoreCallback(this));
}
LeaderBoardSubmitScoreCallback:
#Override
public void onResult(Leaderboards.SubmitScoreResult res) {
Log.d("mylog","leaderboard upload result "+res.getStatus().getStatusCode()+": "+res.getStatus().getStatusMessage());
if (res.getStatus().getStatusCode() == 0) {
activity.showToast(activity.getApplicationContext().getString(R.string.score_submitted));
}else{
Toast.makeText(activity.getApplicationContext(),activity.getString(R.string.error)+": "+res.getStatus().getStatusMessage(),Toast.LENGTH_LONG).show();
}
}
From this documentation, Error Code 6: STATUS_NETWORK_ERROR_OPERATION_FAILED means that a network error occurred while attempting to perform an operation that requires network access. You can retry it later. It might be setup issue so make sure that you have to enable real-time multiplayer support in the Developer Console. You can check on this troubleshooting documentation. Here is a related SO question which might help.
My code was correct. After I deleted the project in my developer console and set up a new one it is working.
I'm trying to disable retries for some specific exceptions completely.
I know that in my code - when I'm trying to handle message X and if the handler throw a "ZZZ" type exception, I'm sure there's no way any number of retries would help;
What I want to do is send that message directly to error queue immediately without any retries.
How can i do that ?
I know you've already accepted an answer, but since you are trying to circumvent the plumbing builtin for a very specific scenario, you could handle the message in a try/catch and either send the message directly to the error queue or let the FLR/SLR handle it.
Please note, this is not an ideal scenario. In most cases, it is actively discouraged to handle the error handling of messages and instead allow the infrastructure to manage it.
Here's a possible implementation:
public void Handle(SomeCommand message)
{
try
{
//Do thing that might throw exception
}
catch (SpecificException ex)
{
_bus.Send(new Address("errorQueue", "machine"), message);
}
catch (Exception ex)
{
throw ex;
}
}
EDIT I'm promoting Marcin's comment to be included in this answer so it isn't missed:
Please bear in mind that by using this approach without setting
appropriate message headers you will lose the ability to return these
failed messages to the source queue. Please take a look at this doco
for details: http://docs.particular.net/nservicebus/messaging/headers#retries-handling-headers. – Marcin
Hoppe
You can't for the first level retries, only for the second level retries. I personally wouldn't worry about it (I have something similar, where certain exceptions I know that it won't be fixed). There's generally no downside to letting them go in the FLR.
I've run over a somewhat little problem over the week. The error message upfront this is about:
[30-Dec-2012 15:19:32] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
I think it is because my error handler (see below for details) is turning any error into an exception. I might should prevent that in case there is no stack frame.
Is there an easy way to find out if there is any stack frame or not in PHP?
Details:
On one of my websites I've got an error handler running that is turning every error into an exception, the common ErrorException to be precise.
I introduced it some time ago because the site is mainly legacy code and I wanted to have any issue result in an exception I can finally "catch" in a streamlined fashion an exception handler and give the request a stop.
I put this into class of it's own, the handler is registered and also in parallel an output buffer is opened to catch the output up until the exception is thrown. Basically code like this:
// register output buffering
$r = ob_start(array($this, 'handleBuffer'));
// register error handler
$this->_originalErrorHandler = set_error_handler(array($this, 'handleError'));
// register exception handler
$this->_originalExceptionHandler = set_exception_handler(array($this, 'handleException'));
This worked all fine and dandy until I decided to add another output buffering class into the mix. Just one that catches as well all output and then can do some "post production" on the website, including checking for HTML problems (yes, it's all a bit legacy so actually this is a bit duck-taped, I know). That also worked very fine btw. however not when I made a mistake in the new component:
[30-Dec-2012 15:19:32] PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0
This is basically my problem. Is there an easy way to prevent getting these errors? I somewhat know why the error is given but I'm not so entirely sure so it's hard for me to really circumvent the problem. I tried to release the new output buffer before the script enters the new shutdown phase because I thought this would cause this. But this didn't make it.
Your problem indicates that you are using an EOL (End Of Life) version of PHP (specifically PHP < 5.3.0), which means it's no longer supported. This issue comes from throwing an exception where no strack frame exists and as such the old engine did not know how to handle those exceptions properly.
This can be due to a couple of different reasons. Some of the most common ones are as follows:
You threw an exception from inside an error handler or exception handler.
You threw an exception from inside a destructor.
You threw an exception from inside a callback (like an output buffering callback function).
Here's an example that demonstrates your problem under some of those circumstances...
function myErrorHandler($errno, $errstr, $errfile, $errline)
{
throw new ErrorException($errstr, $errno, 0, $errfile, $errline);
}
function myExceptionHandler($exception) {
echo "We got an exception with message: '{$exception->getMessage()}'";
}
function myCallBack($contents) {
trigger_error('ohnoes!'); // You can't throw an error from the output buffer callback function in older versions of PHP < 5.3
}
class Foo {
public function __destruct() {
trigger_error('ohnoes!'); // You can't throw an error from a destructor in older versions of PHP < 5.3
}
}
set_error_handler('myErrorHandler');
set_exception_handler('myExceptionHandler');
The above code would cause you to see the fatal error you described here...
ob_start("myCallBack");
... and here...
$foo = new foo;
This problem has been fixed in PHP >= 5.3.0 so you should not see this issue if you were using the most current version of PHP.
The simplest fix is to upgrade your PHP. If that is not an option you must consider these facts that you can not throw exceptions where PHP does not expect them to be thrown (in callback functions, error handlers, exceptions handlers, etc... -- which are actually all considered to be callbacks to PHP).
The other thing is you should not be turning every error into an exception in this way. If what you are doing is as the code I supplied demonstrates (i.e. throwing an exception from inside the error handler -- thus turning every error into an exception) then you are going to cause yourself a lot of pain and with virtually no benefit. PHP errors are not meant to be handled. They are meant to inform the client of a problem (the client being the person writing the PHP code), or potential problem. Handling the error itself is not as simple as turning every error into an exception and then handling that exception, because not every error should be exceptional. For instance, E_NOTICE level errors have no place in exception handling. They are primarily used to notify you of a potential for a bug, not that there is necessarily something buggy with your code and not to mention that most of them can't even be handled easily in user-space code (they mostly require re-factoring the code itself). I strongly advice against this poor practice.
I am just learning WCF and wrote a Windows Service hosting a WCF service. Ever since I started it in service.msc in the remote server (physically remote, and very slow) I think I have already hit and fixed like a hundred errors here and there already. I am now finally stuck.
At this point, I have enabled tracing and message logging. The first and only function call looks like this:
[OperationContract]
public MyServiceResponse ConnectToAXDynamicsViaDotNET2BusinessConnectorWithSadFace()
{
try
{
throw new NotImplemented();
}
catch(Exception ex)
{
return new MyServiceResponse(ex, ex.Message);
}
}
[DataContract]
public class MyServiceResponse
{
// ...
}
Upon calling the operation, the client just sits and waits until timeout. Checking the trace, it records my thrown exception. So it makes me wonder if WCF actually blocks there and ignore my catch clause.
I then tested with just a simple return value without throwing and it FINALLY works.
My question is, how then can I make the above scenario work, ie. catch the exception and return a sensible result back to client? Maybe it's just the tracing that blocks me, but I want to enable tracing during this whole debugging process otherwise it's really hard to work.
Thanks for your precious help!
EDIT: Sorry, I found this right after I posted this question. Happens all the time: http://msdn.microsoft.com/en-us/library/ee942778.aspx but I have yet to read it as I got to run off now. Not sure it it will solve my problem.
Risk being downvoted, but just for documentation sake and general usefulness of having this question:
Through reading the FaultException handling articles, I guess the above behavior is due to Exception class not serializable. And the service silently disconnects itself without returning any error messages eventhough the "send (unknown) faults to client" is enabled. As for why it does so, I have no idea yet. Will update if I find out more.
I have since changed to throw new FaultException() instead of returning my own MyServiceResponses.
I was designing an Activity today and I came across an issue by which rethrowing an exception within the Catch of a TryCatch block does not execute the Finally which is also associated with it. Upon further investigation I came across the following
http://connect.microsoft.com/wf/feedback/details/557601/try-catch-activity-never-executes-finally-if-exception-propagates
Can anyone explain to me what the use of the finally block is in this activity if it is not guaranteed to execute?
The only case I can see is if you have nested try blocks.
if you follow some links from that connect page you will reach this page where you may find an answer... the gist is:
The normal WF functions like
try
{
Environment.FailFast("Game Over.");
}
finally
{
Console.WriteLine("Not Called");
}
the solution is (quoting steve danielson from that page):
If you specify Cancel as the behavior for unhandled exceptions escaping the root of the workflow then it should give the desired behavior. I have passed this feedback along and will ensure that the documentation is updated to reflect this.
ie Workflowapplication.OnUnhandledException = UnhandledExceptionAction.Cancel
HTH