|
You didn't read my post? There are different portions of the IL set used by both languages.. its why they are different. This isn't subject to opinion, its stated fact. Seriously, don't take my word for it:
The book is 'Expert .NET 2.0 IL Assembly Language'.. the author is Serge Lidin, HE IS THE DESIGNER OF THE IL LAYER. Most of the language uses very similar constructs.. but NOT ALL.
Are you intentionally trolling here?
|
|
|
|
|
My original post.
Yes not all or Visual basic would be C#.
|
|
|
|
|
With his pants on fire
I read somewhere that there are things that VB can do and C# can't an vice versa though... Think it had something to do with Errorhandling ?
|
|
|
|
|
|
Inline XML? Does C# have that yet?
|
|
|
|
|
|
Its more than that.. some of the object oriented structures in use in the underlying IL differ between C# and VB. Serge Lidin's IL book covers these differences. If you have to read both languages (and sometimes I do), its useful to know.
|
|
|
|
|
You can write code that fails completely silently in other languages too
|
|
|
|
|
|
What if Pictures is null?
|
|
|
|
|
If pictures is null the memory space creates itself and returns a empty album list
|
|
|
|
|
I think he is referring to the empty catch, it was my first thought. Oh a new version of resume next
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
He asked what if pictures were null.
It's actually a shared class, and this procedure is only for displaying what is in the system.
|
|
|
|
|
Absolutely.. Its remarkable easy to write bad code, given how much of it I've seen over the years!
|
|
|
|
|
Colborne_Greg wrote: Catch
End Try
No, it doesn't need more credit; and your example sums up nicely why VB got that reputation
Yes, you can swallow exceptions in other languages too, but it doesn't happen as often there as it does in VB.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
That's just laziness and the expectation that it works 100% of the time
|
|
|
|
|
..and also something that happens quite often in VB. And no, one cannot call it lazy - the author of said snippet included TWO handlers to swallow the exceptions. That's not lazy, that's extra work.
It could be improved by simply REMOVING the check completely.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Most of that code is autocompleted
also the inside catch is to ensure the loop continues
|
|
|
|
|
Colborne_Greg wrote: also the inside catch is to ensure the loop continues Now you're swallowing 10.000 exceptions in a loop
After that a "File Saved Succesfull" dialog and pretend nothing ever happened.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
No the problem is when one error exists it kills the loop half way through, this code is only run to display results on the GUI, so not only do I not want it to fail for one error, I don't want it to waste time trying to figure out anything related to that error.
I am only unidex the only errors that get through to a client are typos, such as bad filenames
|
|
|
|
|
Colborne_Greg wrote: so not only do I not want it to fail for one error It's wrong. If there's an unexpected error, then the loop should break. That's always better than hiding the exceptions.
Colborne_Greg wrote: I don't want it to waste time trying to figure out anything related to that error. You cannot be bothered to check your own code if it reports an error. I would recommend your users to make backups. Very frequent.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
This is only for displaying data.
Apparently you want the user to wait for typos for each action, instead for a daily report of problems
you are not god, you do not know every angle to program.
|
|
|
|
|
Colborne_Greg wrote: Apparently you want the user to wait for typos for each action, Apparently I'm talking against a wall and wasting my time.
If you trash the users' database just tell them to ignore the error and move on.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I am using Unidex and not a database, Unidex does not have null issues.
|
|
|
|
|
When you're trying to access data from any source that is not in your application memory already, then you should consider the possibility that the data connection might get corrupted for unexpected reasons. Depending on how the connection is working, follow-up requests may clog the input queue and lead to the application blocking, which is just as inconvenient - or even more so - as an app crash!
Not dealing with exceptions and at least trying to find out if it reoccurs is just a recipe for trouble. If nothing else, it's a security hole waiting to be exploited.
At the very least you're potentially wasting a lot of time waiting for responses to data requests that never arrive. If the user wants to display 5000 data records, and your loop gets a 'connection timed out' exception every time, just how long do you think the user is happy to wait for a response?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|