I think perhaps we are all here not really far off a similar opinion on these things.
…. I consider a scale of 0% to 100% , where
_ 0% is where you would use error handling just like you would any formula or function in Excel or VBA
, and at the other extreme
_ 100% is somewhere near Chris thinking close to everything can be done without it.
I think a lot of people would be like Hans at 90% - using it mostly when he does not know of a way to do something without it, ( because there most likely isn’t), or when it is a nice efficient way to do something. I might be at 95% but only because I often don’t need efficiency and the extra coding to do something I find interesting and pretty. ( I might go up more towards 100% depending on what Chris tells or shows in the next year or two…. )
You will have generally a lot of people close to 0% I think. They simply just don’t know yet, as they are new to VBA and or computing generally, or they just don’t care too much one way or the other. Occasionally they may be very stupid, or pretending to be: - like the guy that puts On Error Resume Next
at the top of his macro then posts… I just need a very tiny bit of help. My code is perfect, no errors at all, it just isn’t doing what I want …
I don’t think many people are in the middle. So really we all in the thread are pretty well close to the same opinion I think.
I expect if my (ex) Mother–In-law visited for a longer time then expected, I could get her up to 85% after a bit of careful explanation of the subject.
ChrisGreaves wrote: ↑
19 Mar 2023, 10:51
Jay Freedman wrote: ↑
18 Mar 2023, 21:58
If VBA was a truly object-oriented language instead of an unholy alliance of MS Basic and sort-of-objects, there would not be an On Error statement at all. Instead, as in C++, Java, and (!) PowerShell, the try-catch structure would be the standard for just about everything.
I can live with that.
Yes I too can live very happily with that, and it was pleasing to read. Without the wider experience in computing or others, such as, Jay, I have had similar thoughts based only on gut feeling, but was not sure, so a more qualified confirmation is helpful, thanks.
We disused this non perfect object-oriented language in VBA before
. I thought maybe it was a bit Anarchistic at the time, not adhering to the Hierarchy ideas which are often presented at an early stage of learning object-oriented- programming, (OOP).
Perhaps the transgression from the norm is not always a bad thing, if perhaps it is done in a not too reckless way. Such transgression form the socially accepts norm can sometimes help to give very useful and novel solutions, which no one ever thought of before. At least that has frequently been my experience.
In the case of Runtime Error handling in VBA, the transgression has possibly resulted in a lot of extra stuff available compared to the standard try-catch structure.
The large amount of extra stuff, is the root of a lot of problems and mis understandings, IMO.
A big problem as I see it with Runtime Error handling in VBA is that all the extra things we have , which could be very useful, simply are not understood by almost anyone fully. The subject is certainly not at all difficult. I am the living evidence for that. If I can understand it fully then anyone can. But the number of permutations of what we can do with the extra available stuff is just so high that I think for most people it does not justify them sitting down and taking the time needed to learn it fully. –
Consider a professional painter, Fred. He buys a tub of paint in a new very unconventional mixture. It gives a few thousand extra possibilities including some extremely nice textures that some people would pay a fortune to have. It requires a good understanding of exactly how to mix and stir it, both to get all these thousands of extra possibilities, but also, to prevent occasionally some new problem occurring that totally messes everything up. The Painter, Fred, really has not got, and probably never will have, the time to go to college for half a year and learn all about it. But he takes a quick crash course from the seller, uses the paint, takes some advantages of the extra stuff, but misses most of them. In fact the new problem cropped up once or twice, once very badly, so from that day on he never uses the stuff anymore and warns others to avoid it..
Back in the real world – What I have seen time and time again: I saw it again just recently: A very respected VBA expert , currently regarded as near the top of the best Tutorial makers. He has the most detailed , usually complete guides to subjects in VBA, and is almost as verbose as me when he write Blogs or tutorials! He personally told me he was putting off doing a Tutorial on Runtime Error handling in VBA until he really understood it fully. A few months ago he finally did such a Tutorial. He has missed out about two thirds of the subject, badly confused two distinctly different things, and got a few things blatantly wrong. A few thousand programmers will have a similar experience to Fred now, and then go on to warn others of the bad things in Runtime Error handling in VBA, because of their ignorance and stupidity in the subject. But I am not criticising, and definitely not intending to insult anyone
. These people are all far smarter than me and know tons more about VBA then me. I just prefer to understand fully the little I do know, well at least in computing software anyway, - I always thought it should be an exact subject. That’s all, :-)
ChrisGreaves wrote: ↑
17 Mar 2023, 19:01
it should not be labelled "On Error" at all, but rather "On an error that could not be anticipated ahead of time
I agree generally that the terminology is bad generally. That adds to the confusion, and makes it require even more time to learn it all, because it’s easy to get knocked off course. There may be some secret logic to the terminology that is proprietary / confidential, but to the end user the words used are both confusing and in some cases misleading.
ChrisGreaves wrote: ↑
17 Mar 2023, 19:01
... on our roads ... there are no accidents, only collisions.
Exactly, future car “accidents” will be caused by software glitches