Or using the program on a different CPU that lacks the "invalid opcode"?
I'm not sure what you're getting at with that. If a program is functioning correctly and, it is not dealing with resources managed by code that is not its own, there should not be any exceptions.
Also, these days, programmers are raising exceptions because they buried themselves in a pile of function/procedure calls and the only way they have left to inform the original caller something went wrong is by raising an exception (extremely poor programming!.)
Keeping all the code in one function and returning false or any value to indicate the exact error is not much different.
It is very different and, I believe you know that. An exception is a goto across stack frames. The worst kind of goto there is and, to make exceptions even worse, the final destination can very often only be determined at runtime. When a function returns a value to indicate something went wrong, it unwinds the stack in an orderly fashion (no cross stack gotos there), the final destination can always be determined by simply reading a listing of the code.
And there is another "little" difference. I attached a drastically abbreviated PE dump of a DLL that uses exceptions instead of functions that return a value. When using functions that return a value, the program doesn't get saddled with that pile of junk because it is not doing cross-frame gotos which is what makes the exception directory/table necessary.
The PE dump is of a DLL most people have on their computer, it's Chrome_Child.dll.
Taking either extreme is simply poor programming practice, and does not help readability nor prevents bugs.
I don't consider a function returning a value that indicates something went wrong as an extreme, I consider it clean programming, unlike cross stack/scope gotos currently baptized as "exceptions" to make their use sound "kewl".
Using enough functions that return error codes, or objects that raise exceptions carrying error codes and messages, both are simply two styles of programming. You can abuse either one.
Yes, spaghetti code is also a programming style, that doesn't make it good. I don't recall seeing a program where I would say the programmer abused functions returning error codes to the caller. I have seen plenty of OOP code that misuse and abuse the use of exceptions.
You should, it is just a style of programming.
just like spaghetti code is a "programming style" too.
It is hard to imagine an applications that does not deal with the internet, json, networks, databases, acquired data from wired/wireless sources like images or ... etc.
That's true but, I've dealt with the majority of the things in your list and I have not needed exceptions.
otherwise the programmer should write clean code, which means do all the necessary checking before carrying out the function.
This applies when using OOP or not.
Yes but, OOP programmers seldom do it that way. What's seen more often than not is, code that doesn't check for anything and simply wraps statements in exception handlers. When something goes wrong, the exception handler gets to have a look at what happened, if it is clueless as to how to fix the problem, it simply re-raises the exception passing the buck to who knows what code.
or depend on libraries that do use exceptions.
That's defines the typical case: a poorly written library spreads its poor design to the program that wants to use it. Apparently, it's too much work these days to return an indication of failure or success as a function result. Using exceptions makes a programmer look "kewl" and knowledgeable. Function results ?... way too prosaic these days.
I hear you, you prefer to use a library and with each call to check the result: Initialize the library, check. A call, a check. Another call, another check, repeat... , finalize the library, then check.
Yes, I definitely prefer that because when something goes wrong, the calling function/procedure is the one that gets to know about the problem (that may not be the case when using exceptions) and the caller can figure out what the proper course of action to take is, not some exception handler who knows where which may not even have been programmed with the proper way of handling a problem from the code that raised the exception.
I will give you this, there are times when I have found all the checking to be tedious but, I'd much rather do the tedious work than writing a program that is just 21st century spaghetti code covered in exception cheese.
You don't like to include all of that in one block and leave the checking to the library itself? It would keep your code focused on its own part. But again, this sounds like your own style of programming, I have nothing against it. I can imagine how if thisVar=someErrorValue then grows in your code.
That's not quite it. It's usually, "if functionreturn = false then <either handle the problem or exit if it cannot or should not>"
Not checking for function results is another one of those bad habits coming from C. If it's a function, it's return value should be checked, that's why it's a function and not a procedure.
For the record, I don't have anything against anyone's programming style but, I do have something against OOP. I find the results usually leave a great deal to be desired and, the really unfortunate part is that truly deficient programming practices have been coated in impressive sounding names to make them "attractive". Cross scope goto (formerly known as longjmp) have been renamed "exceptions" and to make them even "nicer" the destination, unlike in the traditional goto, is dynamic. Welcome back to COBOL's ALTER statement. A statement programmer's got fired for using, now that it goes by the name of "exception", it is "kewl".
I want to let you know that JAVA does have exceptions and you have to catch them, and, unfortunately, FPC can produce JAVA classes, run on JVMs, and interact with other JAVA classes.
Fortunately, Java isn't and is rather unlikely to ever be one of my concerns.
Exceptions are just a tool. Like any tool, they need to be used right.
I agree with that. These days they are grossly abused and misused.
Anything could be abused of misused, does not mean we need to avoid it, or consider it poor practice.
In generic terms, as you've stated them above, I fully agree with that. That said, my point is that the entire exception mechanism is very poorly implemented, grossly misused and equally abused.
Yes, until you are forced.
I can see being forced to have exception handlers (as you pointed out if the program is using a library that raises exceptions, that leaves no choice) but, I don't see how a programmer could be forced to use try/finally.
The debugger, when enough debugging data is available, is supposed to show you exactly where the exception had happened before it takes you anywhere else. But if you don't like try/finally for that reason, then you do not like else either because it jump somewhere far from the line the debugger was on.
True that the debugger will usually be able to show exactly where the exception took place. No argument there. That said, when resources need to be released, the code execution is going to jump around to each and every one of the try/finally(ies) not so in the case of an if statement, it will execute whatever is in the if, that's it, no jumping around.
It is not clean, and not supported by Pascal, but you used it. While Try/Finally is part of the language, the object oriented dialect, and you refuse to use it?
I openly admit that I'm not fond of having to "trick" the compiler in order to get a scope. As far as supported by Pascal, I do believe that "for i := 1 to 1 do " is supported. The one problem in that construct (which I wish I didn't have to use) is that if the optimizer ever gets really smart, it will remove the loop and then complain that there is a loose "break" statement. That is a potential problem.
"Scattered" or not, if deallocation happens in a logical and correct way, and always guaranteed there is no problem. The desire to have all the deallocations in one place came with extra price, at least, the chain of IF THEN. Again, a style of programming.
Scattered is a problem because the programmer has the burden of mentally assembling all the little "pieces". Definitely less than desirable.
Yes, a call to member function of an object like AStringList.Add is actually a call to a function with the first parameter is the object itself: Add(AStringList,... see?
It is like adjectives are before/after the nouns in different languages:
English (Brown Horse)
Spanish (Horse Brown)
Which one do you prefer?
No, that example doesn't reflect the problems with OOP. It isn't simply a matter of syntax. Here is a question for you, why do you think it is customary/standard to prefix object fields with some letter, usually the letter F ?. It isn't to make them look pretty.
I might give it a shot, not sure.
I offered only so we could compare specifics instead of staying in the realm of "theory".
When the level of nesting grows, it is time to consider another function/member function.
That's not a good solution either because it breaks the logical flow into a bunch of little pieces and the programmer has to go find them to read them, then mentally assemble all that stuff to see what the complete logic is. A programmer should be designing algorithms and data structures not assembling binary jigsaw puzzles.
Now I believe that you have your own style of programming and refuse to change it, not because it protects you from bugs, but simply because you do not want to try something new. Nothing unusual here, but considering other ways as poor or more prone to bugs is not accurate.
That is not the case. My programming style changed a lot over the years (Per Brinch Hansen is responsible for the greatest change). Whenever I see a better way of doing something (which I define as something that simplifies the code or helps prevent potential bugs) I take it on the spot. OOP is definitely not one of those things.
This whole thing started with "exceptions" and whether people use them or not. My premise is that they can be, on rare occasions, extremely useful - usually when writing code that sticks its bytes where they probably don't belong - but, for normal programs that are not fiddling with resources they don't manage, the use of exceptions is not justified.
Just in case, I want to make sure the following is clear, this is a completely friendly discussion. I know that I tend to support my viewpoints a little bit more "vigorously" than is thought of as friendly. I mention it because I don't want it to be misinterpreted.
ETA:@Handoko
You're welcome!.
ETA 2:Added missing attachment.