|
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)
|
|
|
|
|
Unidex manages the problems, its a connectionless state, serialized, time stamped, with automatic collision detection, that produces a daily report of user errors. It even comes in a marshalled version with a web api for web services.
100% of SQL related errors and practices are gone.
|
|
|
|
|
Now you're sounding like advocating some religious sect. I mean, nobody here has ever heard of Unidex, witnessed it's superiority, or revels in the light of its magnificence.
If it sounds too good to be true, it isn't.
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)
|
|
|
|
|
I started writing Unidex in 2002 when I was trained on .net 1.1 by Microsoft. It's been in use by Realty Executives since 2007, I created the web API and services last year.
Windows 8 apps are the first to showcase Unidex in a public forum.
Except for the serialization process of Windows 8 all I had to do was copy the code into a portable library and the code works.
You can see some primitive examples of Unidex software by looking up our facebook page, which hasn't been updated in a while, advertising is never something I have had to do to be successful.
|
|
|
|
|
How often I have seen something like that. And then the criminal who wrote this thinks he's being treated unjustly and exclaims something like "But it always has worked!".
And then try to explain to Mr. Pointy Hair that this mess only pretended to work at best, fell flat on its face and was more busy covering it up than anything else at worst, and that looking away will not solve anything or save us one single cent.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.
|
|
|
|
|
First off criminal? no learn English maybe
Secondly if you understood English you would know that a sentence doesn't start with and.
|
|
|
|
|
Just an aside.. I absolutely love your sig..
"the language is JavaScript. that of Mordor, which I will not utter here"
LOL. I'm a sucker for Middle Earth comments and disparaging comments about Javascript!
|
|
|
|
|
I totally agree on that most of the complaints about VB is of the immature kind.
But one thing I need to give them is the On Error Resume abomination.
Which you sadly have emulated with your empty Catch. 
My personal opinion is that since C# and VB.Net is based on the same CLR and the same Framework, most quarrels are just silly.
Use what you feel most at home with, but stop being ridiculous about it!
|
|
|
|
|
I took a job once, with no knowledge of VB (Visual Studio 6). Hey, I just wanted a well paying part time job to finish my master's degree.
One of the 'best practices' of the company was to always add "On Error Resume Next" at the beginning of each and every function. I asked why, and the reply was that it just works better that way.
The job paid the bills, I graduated, I got a new job, the company went under (not because I left, but I saw the writing on the wall ahead of time - they had too many people and no contracts lined up).
|
|
|
|
|
On Error Resume Next
Is from before the .net era and is a bad programming practice
|
|
|
|
|
I should have left out the try catch
|
|
|
|
|
|
When dealing with a database, sometimes there are bad records.
I meant for these try catches to be this way, as I don't care at this point why there would be problems in the data, all other errors are handled.
|
|
|
|
|
Then catch the DB errors and rethrow the rest.
|
|
|
|
|
|
Heh? so you don't want your user to know to tell the DBA or YOU that something is wrong between the application and the database it uses? Hiding such things is asking for problems down the road. BIG problems.
|
|
|
|
|
It does not use a database.
|
|
|
|
|
You know, you could have avoided a whole lot of discussion just by adding a comment saying that. I too sometimes add error handling code that I know I don't really care about, just to make a point that I did consider the possibility of that error. And, of course, if someone later adds to the code, he may need to reassess if the error can really be ignored - if the (emty) error handling code is already there, then it's much less likely he'll forget to deal with it. 
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)
|
|
|
|
|
The code was a quick attempt at a just works client. My laziness just so happened to spill over into this thread 
|
|
|
|
|
It's exactly that 'just works' mentality that needlessly causes hours and days of maintenance effort when it comes to figuring out what a buggy function does, or what it takes to adapt it to a new functionality without introducing regressions. If you care about the state of your program in 6, or even 2 months, then you should care about comments and think beyond 'just works'.
Not saying or implying that this is your professional style of coding, but it is all that we see here, so don't be surprised if people react and respond accordingly.
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)
|
|
|
|
|
We don't spend time on bugs, we use Unidex.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
