|
Griff called me Richard. He's edited the post to use my name now.
|
|
|
|
|
I made a mistake, and referred to Pete as Richard, is all. No joke, just a mistake on my part.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
oh i though it had a deeper meaning i didn't get 
|
|
|
|
|
oh yes you are right, sorry i have used the wrong part of the code. i edit the question again.
I cant reproduce the bug in my device, it is happening in around 2% of the devices that is being used, this code is from an app that is available from google play already
|
|
|
|
|
You're making the assumption that the method that is throwing the null reference is inside your task. What's interesting is that you have failed to apply any forms of input guards to SearchMostLessViewsAsync and you're assuming you actually have values coming in. It wouldn't surprise me if the null reference you are seeing occurred in this call:
Microsoft.AppCenter.Analytics.Analytics.TrackEvent($"{typeof(FragmentDrawsNumbersFrequency).Name}.{nameof(SearchMostLessViewsAsync)}",
new Dictionary<string, string>()
{
{nameof(dateFrom), dateFrom.ToString()},
{nameof(dateTo), dateTo.ToString()},
{nameof(amountOfNumbersSelected), amountOfNumbersSelected.ToString()},
{nameof(frequencyOption), frequencyOption.ToString()},
{nameof(fromDrawNumber), fromDrawNumber.ToString()},
{nameof(toDrawNumber), toDrawNumber.ToString()},
}
);
If any of those is null, you'll get a null reference because you're calling ToString() on it. The bottom line is that you shouldn't make assumptions about where exceptions are occurring; look at the whole part of the code.
|
|
|
|
|
hello, those values cannot ever be null from the way im setting them app and also from the crash reports they are not null, they have a value, the crash comes later. some times this code doesnt crash. some times it does. even in the devices that crash it doesnt crash always.
From what i understand my biggest problem is that i dont try catch inside the task and i loose exceptions because of that. I have added a try catch inside the task and now i see that even in my device thaat never crash sometimes i get an error about ssl.
The correct way is to check all those values if they are null in the beggining of the function even if by the way are initialized always have value?
|
|
|
|
|
im Programing one Program(editor)
my question is how i can open one file txt in open with in right click and my program read the file
can you help please???
I searched for this question a lot but I could not find anything. Please help me find the answer to this question.
thanks
|
|
|
|
|
You're going to have to be more specific. "Right-click" in what?
|
|
|
|
|
|
I see a lot of tutorials and examples that define controller methods like this:
[HttpGet]
public async Task<IEnumerable<Book>> GetBooks()
{
return await _bookRepository.Get();
}
[HttpGet("{id}")]
public async Task<ActionResult<Book>> GetBooks(int id)
{
return await _bookRepository.Get(id);
}
In these examples, the method signature returns a Task so that the method is async.
But can I just do this in my front end?
private async void LoadBooks()
{
List books = null;
await Task.Run(() =>
{
books = _proxy.GetBooks()
}).ContinueWith(x =>
{
Books = new List(books);
});
}
Why make the controller methods return task and use await? Doesn't my front end code acheive that?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 29-Sep-21 17:47pm.
|
|
|
|
|
The reason that you return Task from an async method rather than void relates to the fact that returning void consumes exceptions that are being thrown. If you return Task, you have the ability to handle the exception gracefully. As for your code sample, you don't need to add an await on a Task.Run to get the ContinueWith to happen. In fact, you should remove that await altogether - if you're manually running up a Task here, you don't need async/await constructs.
|
|
|
|
|
If a controller method is returning Task or Task<t>, then my front end method would need to be async, correct?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
The async-ness of your front-end methods is unrelated to the async-ness of your controller methods. You can have an async front-end method calling a non-async controller method, or a non-async front-end method calling an async controller method.
The front-end code is making a network request. It doesn't know or care how that request was fulfilled. The server could be using a synchronous method, an async method, or waiting for a carrier-pigeon. The front-end just needs to wait for the response.
Having said that, your front-end method should always be async if possible. It's making a network request, so you don't want to block a thread waiting for that to complete.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: The async-ness of your front-end methods is unrelated to the async-ness of your controller methods. You can have an async front-end method calling a non-async controller method, or a non-async front-end method calling an async controller method.
OK, so when I try this:
private async void GetSomeData()
{
var myData = await GiveSomeData();
}
private int GiveSomeData()
{
return 10;
}
I get a compiler error because GiveSomeData doesn't return a Task. How then do you call asynchronously call a method like GiveSOmeData?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Within the same process, you can only use await when you're calling something that returns an awaitable object. That typically means either a Task or a ValueTask.
Your question was about calling a Web API from some front-end code. Those are two completely separate processes, which communicate via a network request. They know nothing about each other. They could be written in completely different languages.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I see. Thank you
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
async is not really about multi-threading; it's about not blocking the current thread waiting for an external resource.
In your example, there are two external resources - the API, and the database.
The front-end call needs to use an async call to the API, since it's a network request which could take a while to run. You don't want your UI thread blocked whilst it's waiting for that request to complete.
The controller methods need to use async calls to the database, since that's potentially another network call, plus disk access, plus the time it takes the DBMS to parse and execute the query.
Think of it like a car trip. In the non-async world, your kids are in the back seat constantly asking "Are we there yet?" over and over again until you arrive. In the async world, your kids sit quietly watching a film on their phone, and wait for you to tell them once you've arrived. One of those options is extremely irritating. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you for clarifying.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Using MakeGenericType and Activator.CreateInstance() to make a generic Type at runtime returns an Object: to make a usable instance of that Object, you have to cast it to its "native" Type.
surprise: i stumbled across a way to get a usable instance of the Object ... without explicit casting ... by using 'dynamic'; example:
Type generic = typeof(Dictionary<,>);
Type[] typeArgs = { typeof(string), typeof(string) };
Type newGenericType = generic.MakeGenericType(typeArgs);
dynamic instance = Activator.CreateInstance(newGenericType);
instance.Add("1", "2");I am not sure, how, in this case, use of 'dynamic' works.
Appreciate your thoughts.
Note: afaik, no example of this technique occurs in any MS documentation.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
dynamic uses late-binding. Behind the scenes, it will use reflection to find and invoke the appropriate Add method on the run-time type of the object, with a suitable sprinkling of call-site caching to improve performance.
Simon Cooper published a series of blog posts on that topic back in 2012:
Inside the DLR - Callsites - Simple Talk[^]
Inside the DLR - Callsite binders - Simple Talk[^]
Inside the DLR - Invoking methods - Simple Talk[^]
NB: For the generic collections, you can probably avoid the DLR overhead by using the non-generic interfaces instead:
Type unboundType = typeof(Dictionary<,>);
Type[] typeArgs = { typeof(string), typeof(string) };
Type constructedType = generic.MakeGenericType(typeArgs);
IDictionary instance = (IDictionary)Activator.CreateInstance(constructedType);
instance.Add("1", "2");
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you ! Your example of using the unbound Type is very interesting.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Dynamic types skip all compile time checking in favour of runtime checking - that includes method names, return types, number of parameters, type of parameters, or even that the method exists at all.
So because the return value is declared as dynamic, the compiler doesn't care what you try to call - and at run time the checks are done and the right method is called.
Try it:
dynamic items = new List<string>();
items.Add("Hello");
items.Add("World");
Console.WriteLine(string.Join(" ", items));
items.FallOverAndDie();
Will give you:
Hello World
Unhandled exception. Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: 'System.Collections.Generic.List<string>' does not contain a definition for 'FallOverAndDie'
at CallSite.Target(Closure , CallSite , Object )
at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid1[T0](CallSite site, T0 arg0)
at Program.Main(String[] args) Because the collection does not contain a FallOverAndDie method.
dynamic items = new List<string>();
items.Add("Hello");
items.Add("World");
Console.WriteLine(string.Join(" ", items));
items = new Dictionary<int, int>();
items.Add("Hello");
items.Add("World");
Console.WriteLine(string.Join(" ", items));
Will fail because the Dictionary class has no overload with just one parameter.
Personally, I'm still not convinced that adding dynamic to the language was a good idea - it seems too much like a way to move compile time errors to runtime and break strong typing ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks !OriginalGriff wrote: Dynamic types skip all compile time checking in favour of runtime checking
I was aware of that, but, still felt there was some "spooky action at a distance" going on when it came to this specific type of Type creation.
i find the two examples that "fail" rather strange in this context because they contain rather obvious programming errors ... i think your point is the lack of compile checking, which is generally known by anyone who uses 'dynamic.OriginalGriff wrote: Personally, I'm still not convinced that adding dynamic to the language was a good idea - it seems too much like a way to move compile time errors to runtime and break strong typing ...
imho, that's a very interesting topic for debating what a supposedly strongly-typed language should expose for use by programmers.
Should it expose reflection, and dynamic, facilities ? Allow use of facilities that allow access to OS internals the way C# lets you use API's ? Expose Activator ? Expose a REPL facility ? i suppose an "extremist" might even oppose facilities like generics, and Linq, and extension methods.
i see use of 'dynamic as "dangerous," but useful when you absolutely have to have a "bag" of mixed Types and use of casting to interface is unwanted ... a whole lot better implementation than the now deprecated 'ArrayList.
The run-time creation and instantiation of generic Types seems valuable to me for creating object factories.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I can see the intention, but I think that (just like var) it's too open to abuse.
With dynamic you can "get rid of all compiler errors" and provided your tests never reach the "bad code" you won't know until it fails in production. Which is against the whole ethos of C# and strong typing ...
It's a personal thing: I don't like production errors that I can catch as early as possible in the development process.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I hear what you say, and I think using Dynamic is similar to surgery ... you want it performed only when necessary, and, you want a specialist using the knife, not your pharmacist
If I want a "bag" of objects of various Types ... the number of them, and their Types, known only at run-time ... Dynamic and ExpandoObject are usable ... without the gut-busting required to use something like Reflection/CodeDom/Emit.
The creation of generic "factory classes" that create specific instances of Classes at run-time is, imho, a kind of special case.
imho, later versions of C# added generics, Extension methods, Dynamic, Linq, use of var, etc., because there was a compelling demand for them.
cheers, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
