I have been getting very frustrated with Dart as runtime exceptions seem to fail silently. Program execution will continue after some type of failure and leave me totally stumped about what is not working and why. For example, in using aqueduct for dart server (this is not an issue unique to aqueduct, but dart in general) I have this code:
jsonData.forEach((jsonObject) async {
ManagedObject record = Document();
record.read(jsonObject);
print(Util.jsonFormatToString(record.asMap()));
....more code
}
In this case, the application fails silently on record.read() falls out of the forEach loop and then continues code execution. During debugging, the application returns completely strange results and after debugging, presumably there is a problem with the jsonObject attempting to be read into the managed object, but Dart gives no notice that there is a problem or what that problem might be.
This is one example of many I have been running into.
Why does Dart fail so silently or am I missing some setting somewhere that is hiding critical info? I am using IntelliJ IDE.
Related
My DES model was working well till I've added a new function (just like many others added before) and the model gave me all these error messages:
I wonder what do these messages mean and what made all of them appear suddenly. I was running the model just before it without any errors. Is there a way I could get my model back? :)
Thank you.
Edit 1:
Here is the newly created function: Newly created function
Given that I've ignored it, and made all the callings of it as comments, then the errors were still appearing. I've closed this model version and opened a backup then created the same function and the whole scenario happened again with the same 94 errors.
Is there something I need to change in the function itself?
The function checks the number of agents in certain parts of the model to stop delay blocks accordingly. That's done by adding variables that increment on exiting of agents and get the difference between them.
Typically this is caused by a syntax error in the new function that you created. See if you ignore this and then compile if it gets fixed.
Most of the time the compiler is smart enough to show you the error, but often if you replace a { with [ or you leave out a { the compiler get very confused and gives you 100s of errors.
If yous still cant find the issue maybe paste the code of your new function in the question.
Xcode has started displaying a compiler error as soon as I open my project (i.e. a build is not required) but it's all a bit odd. One error is shown in the build time tab but when I open the compiler message window there are three identical errors spread across multiple files. The errors are not highlighted in the editor window so I can't trace them but as they're flagged in files I haven't touched recently I suspected the problem was with Xcode rather than my code.
The error is shown in the build time window as:
Swift Compiler Error - cannot convert value of type '()' to closure result type 'Observable<Void>'
In the messages window:
<unknown>:0: error: cannot convert value of type '()' to closure result type 'Observable<Void>'
These errors are spread across three files in the messages window, all of which use at least one RxSwift dependency (RxDataSources, RxSwift, and RxCocoa) and, as noted above, I haven't touched a couple of them for a week or two and my dependencies have not been recently amended so I can be reasonably certain they are not the issue.
I've done all the usual (clean, clear cache, reboot, checked error display settings, roll back to an earlier version, update dependencies, reinstall Xcode) but the error persists and I'm effectively locked out of further development until I can resolve it. To say that I'm frustrated would be an understatement!
I'm running Xcode 10.2.1 (10E1001)
Help!!
I took the app apart and then added in each class individually until the error popped up again. The problem was a typo (syntax error) in a view model struct, specifically, the line:
let editTapped = CocoaAction { return }
which should have been:
let editTapped = CocoaAction {
// do stuff
return .empty()
}
I'm guessing the failure of the compiler to highlight the error in the editor pane is a bug so I'll report it (unless anyone has views to the contrary?) as it was very time consuming to sort out. The odd things was that rolling back to a previous working version didn't fix it - I had to delete the entire app and then rebuild it from scratch manually adding the files as I went. Weird...
Well the system we have has a bunch of dependencies, but I'll try to summarize what's going on without divulging too much details.
Test assembly in the form of a .dll is the one being executed. A lot of these tests call an API.
In the problematic method, there's 2 API calls that have an await on them: one to write a record to that external interface, and another to extract all records and then read the last one in that external interface, both via API. The test is simply to check if writing the last record was successful in an end-to-end context, that's why there's both a write and then a read.
If we execute the test in Visual Studio, everything works as expected. I also tested it manually via command lining vstest.console.exe, and the expected results always come out as well.
However, when it comes to VS Test task in VSTS, it fails for some reason. We've been trying to figure it out, and eventually we reached the point where we printed the list from the 'read' part. It turns out the last record we inserted isn't in the data we pulled, but if we check the external interface via a different method, we confirmed that the write process actually happened. What gives? Why is VSTest getting like an outdated set of records?
We also noticed two things:
1.) For the tests that passed, none of the Console.WriteLine outputs appear in the logs. Only on Failed test do they do so.
2.) Even if our Data.Should.Be call is at the very end of the TestMethod, the logs report the fail BEFORE it prints out the lines! And even then, the printing should happen after reading the list of records, and yet when the prints do happen we're still missing the record we just wrote.
Is there like a bottom-to-top thing we're missing here? It really seems to me like VSTS vstest is executing the assert before the actual code. The order of TestMethods happen the right order though (the 4th test written top-to-bottom in the code is executed 4th rather than 4th to last) and we need them to happen in the right order because some of the later tests depend on the former tests succeeding.
Anything we're missing here? I'd put a source code but there's a bunch of things I need to scrub first if so.
Turns out we were sorely misunderstanding what 'await' does. We're using .Wait() instead for the culprit and will also go back through the other tests to check for quality.
So the issue I'm having only recently started after an update to the Lync client somewhere around version 15.0.4849.1000. The issue revolves around app sharing conferences, which I have working fine still in 2016 SFB and anything prior to 15.0.4849.1000.
The core issue as far as I can tell deals with Modality.BeginConnect, the passed in callback does not get called. Although, I have had it get called when I'm debugging, stepping through the code and hitting breakpoints, etc. So that leads me to think that normally maybe something's not getting initialized in time, or some sort of race condition, but I haven't been able to pin down exactly what makes it function correctly in that case.
EDIT: I just realized another exception occurs during the call to BeginConnect:
A first chance exception of type 'System.Runtime.InteropServices.COMException' occurred in Microsoft.Lync.Model.dll
Additional information: Exception from HRESULT: 0x80F10083
And that HRESULT translates to: "The operation is disabled by capability". What in the world does that mean?
The odd thing is (or seems odd to me) that even though the callback is never called, I do receive a ModalityStateChanged event for ModalityState.Connected...
So if you have any ideas what would perhaps cause that, please share!
I don't think these this is related, but a call to this:
m_aeConversationWnd = AutomationElement.FromHandle(m_ConversationWindow.Handle);
shortly before calling BeginConnect, fails with the exception:
A first chance exception of type 'System.ArgumentException' occurred in UIAutomationClientsideProviders.dll
Additional information: Value does not fall within the expected range.
New to scala futures I try to call a web service like
wsClient.url(baseUrl + url).withHeaders("Content-Type" -> "application/json").post(dataForR).flatMap(parseOutlierResponse)
using ply-ws library
I validate & map the response as follows https://gist.github.com/geoHeil/943a18d43279762ad4cdfe9aa2e40770
The main thing is:
Await.result(callAMethodCallingTheFirstSnippet, 5.minutes)
Strangely this works just fine in the repl. However if run via sbt run I get a NullPointer Exception. I already verified the JSON response manually. It validates like a breeze. Even the mapping works great. However, there must be a problem with the futures I am using. But I am not sure what is wrong. It seems like the flatMap method is called before there already is a result.
Interestingly if I do not await the result there is no null-pointer exception, but the parsed result is displayed correctly (however, the program does not exit). But there, where I really use this code, I somehow need to await the successful completion to further deal with it.
Below you will find an illustration of the problem
I do not see any major concern with your code! I made a small test with the following code bit and it seems to be working perfectly, both in the REPL and when using sbt run:
WS.clientUrl(s"http://$hostName/api/put").withHeaders(jsonHeaders: _*).post(body).map { r =>
if (r.status >= 400)
logger.warn(s"Invalid http response status: ${r.status} \n ${r.body}")
else
logger.debug(s"Successfully persisted data. Http response ${r.status}")
}
After more and more debugging I found that some implicits were in the wrong scope and the order of dependent case-classes was wrong. After moving them into the correct scope (the method performing the request) the null-pointer exception is fixed.
I could only find the "real" error after changing from flatmap to map which I find very strange. However, now both methods work fine.