xsharp.eu

Dick,

Returning strings in case of an error does not solve the original problem that I mentioned. You can still ignore the error and create a hidden time bomb in your code.

The only right way to handle error in a base function such as Registry.DeleteKey is to "break" the normal program flow by throwing an exception.

Then the consumer of the code can decide that he wants to ignore the exception by embedding it in a try catch and he can decide to ignore the exception and convert it to an logical return value.

You have to remember that the people that wrote Registry.DeleteKey() and other code in the .Net runtime have no idea where it is going to be used. It makes quite a difference if the program using this code is an app monitoring lives on the Intensive Care of a hospital , an accounting app or a game.
I hope that when a critical error happens in an app in a hospital that the alarm bells will start ringing and that the critical errors will not be ignored because the programmer failed to check the return value of the method call.

Robert

Hello Robert,

Here I totally disagree with you.

A friend of mine used to develop software for medical equipment. There is a strict protocol which must be followed plus many checks - from which I expect much more in terms of properly handling all kind of return values than from the pretty random working of everything Microsoft develops.

When receiving a return value, I can, as programmer, decide if I want the program to continue because the failed action is not critical for the rest of the process. When the program goes into the error handler I do not have this option anymore.

Or in IC software terms: if deleting a registry key fails, the IC software stops doing the job because it goes into the error handler where the alarm bells may start ringing but the patient dies as a result, while if it had returned a string, the programmers could have decided that all or most messages were not severe enough to stop the program executing.

Dick

PMFJI (again)
Hi Dick
I liked Robert’s Hospital Analogy - it was IMO Spot On.
Trying to tie it up with your friend’s Medical Equipment Development misses a very important difference: Environment.
To understand this, I believe you will find it easier to forget code altogether. Do not let what you already know get in the way of understanding something from a different perspective.
On that basis I would ask you to accept the following (I can prove it, but that would take a book):
Everything that happens in a Running Program can be visualized in terms of what we know about, and how we do, things in real life.
Whilst no one knows what is in another person’s mind unless they are told by that other person, it is not too difficult to categorize what is there. There will be mental “pictures” of:
Objects – no real limit to type or characteristics.
Environmental Factors – Earth Gravity, Fresh Air and so on.
Moon – Gravity, No Air, No Water
Animals and their needs – Human, Dogs and so on.
All these factors and many more exist in our minds. They are all independent and not linked in any way. And whilst there nothing happens, we can think about them as long as we like, but nothing will change.
Now if we want to do anything, we know it must involve time (nothing gets done in zero time).
Also, importantly, what is being done can only be done within a tangible environment. In most cases, that environment will be a physical entity in the real world (workshop?). But what if it’s not?
When Neil Armstrong and landed on the moon he had to take his environment with him.
So what had really happened was that the human brain had linked relevant factors in the mind to produce an appropriate environment which did not exist on the moon.
Exactly this is happening in your code. You are taking your coding instructions into a completely empty, barren environment so you must take an appropriate environment with you.
Alternatively, you must ensure an appropriate environment has been correctly set up before you go.
I hope this makes some sense – it is what is going on across the board of your code.

Terry

Hello Terry,

Also after your explanation, I still totally disagree that relying on error handlers (especially in Microsoft code) is a safe way to produce safe code in critical environments.

First of all because, with your sample, the programmer could also have forgotten to implement the error handler (environment). Ergo: program crashes completely, patient dies.

What should be best altogether is that all these functions return a usable value (success as a boolean, error messages, empty if none, as a string) and the compiler forces you to assign that value (so no Skip(-1) but always lSuccess:=Skip(-1)).

It is then becoming less likely that a programmer forgets to implement a proper reaction in error situations (unless on purpose), also less likely that he forgets to enter an error handler. And the flow of control is not disturbed because the program ends in an error handler.

And in case anyone replies that in critical programs an error handler will never be forgotten, my reply is: Right! And reading return values and acting upon them will not be forgotten either in this kind of development.

So relying on error handlers for return values is always a inferior solution.

Dick

Hello Dick

I need to think this through a bit more.

But my immediate thinking is that yes, you are right, the programmer could have forgotten to implement an error handler. And yes the patient will die.

You say:
What should be best altogether is that all these functions return a usable value (success as a boolean, error messages, empty if none, as a string) and the compiler forces you to assign that value (so no Skip(-1) but always lSuccess:=Skip(-1)).

Maybe but you are asking the impossible.

The only way to achieve anything like that is to run a diagnostic program over all your code-base checking for any missed exception and flagging it up. Such a thing is indeed possible and may take a long time, but could be worth it. You are in fact asking for a bug-less program.

You are asking for overall 100% safety. No unhandled exceptions at all.

This is a practical impossibility. It can only occur in the mind.

Remember Calculus? You had to imagine a convergent series to zero to make sense of it. But if you tried to actually calculate it, it would have taken an infinite length of time.

Time is always in it somewhere.

Terry

Dick,
A programmer that writes mission critical code without error handler should either be re-trained or fired. There is no excuse for not having error handlers. We all know that every program is going to fail sooner or later. Every programmer should prepare for the worst.
"Optimistic programming" is only allowed in small examples but not in real life programs.

Let's agree that we don't agree.

Robert

Hi Dick,
please let me add something: I don't like the error handling in .NET at all because I prefer to not have to deal with so many exceptions.
A bad sample for me is how the String:SubString() method is implemented - therefore I wrote my own version that behaves like the VO SubStr() function. And IMHO the .NET error handling requires too much code and sometimes there is more error handling code than execution code.
But nevertheless I agree with Robert that error handling is absolutely essential - I call it "defensive" programming because for every line of code I'm writing I think what could go wrong in this place. That saves a lot of time later in production....
Wolfgang

Hi Wolfgang,

Why does it require too much code? It is your option to deal with every different possible exception, or just manage them all together, as you would do in VO:

TRY
// code throwing exceptions
CATCH oException AS Exception
// deal with any exception that may happen
END TRY

Why is this any worse than VO? And in .Net you have the option if you want it, to add multiple CATCH statements for different exceptions, something which is not possible in VO, but it is not mandatory in .Net either.

Hello Wolfgang, Chris,

Chris wrote: Why does it require too much code? It is your option to deal with every different possible exception, or just manage them all together, as you would do in VO:

I agree with you here Chris. Apart from the {} (in C#) of course I think that error handlers in .Net are one of the few things which are more straightforward. I never liked VO's

cobOldErrFunc := ErrorBlock( {|oErr|_Break(oErr)} )

etc.

Dick

Hello Robert, Terry,

robert wrote: A programmer that writes mission critical code without error handler should either be re-trained or fired. There is no excuse for not having error handlers.

It looks like both of you missed my point: it's just as unlikely that programmers and their supervisors of mission critical software forget to evaluate each return value and decide upon these values what to do next, as it is that they forget error handling.

However, if they have to rely on error handlers they have no option anymore (as far as I know at least) to continue. With return values they have. So any method, function, should return the best usable values for everything that can go wrong and can be foreseen more or less. Error handlers should be, of course, but there for everything which can't.

.Net is an inconsequent mix of methods with return values and (often void) methods that rely fully or partly on error handlers. So not for getting e.g. any of the 6 errors which can occur from running Registry.DeleteSubkey (as void) and which could much better have been returned as string return values.

Dick