|
Consider these two C# statements:
public delegate bool IsItSafe() ;
public event IsItSafe Probe ;
they compile just fine and actually work as they should, but the VB.net equivalent:
Delegate Function IsItSafe() as Boolean
Event Probe As IsItSafe
yields:
C:\Projects\Template.vb(26) : error BC31084: Events cannot be declared with a delegate type that has a return type.
Event Probe As IsItSafe
~~~~~
Not that it's something that is common, but I do use a few events that return bool values in an unusual project of mine.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
|
They use the same underlying IL machine. I don't think its said anywhere that they are exactly the same.. If you read the book on the IL assembler the author talks in great detail on the differences between VB and C# and how the IL abstractions express them both. That qualifies this argument as a strawman.
|
|
|
|
|
Wrong.
You just gave the exact details of the situation reinforcing their similarities.
|
|
|
|
|
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[^]
|
|
|
|