[fpc-pascal] using exceptions

[Marcos Douglas]

On Tue, Jan 3, 2012 at 7:20 PM, Lars <noreply at z505.com> wrote:
> Marcos Douglas wrote:
>> On Thu, Dec 22, 2011 at 4:17 PM, Anton Shepelev <anton.txt at gmail.com>
>> wrote:
>>> Marcos Douglas:
>>>
>>>> It's  not  difficult,  but is boring have always a
>>>> parameter or function return to return  an  error,
>>>> and  have  to  verify  if error then... if not er-
>>>> ror...  if error and error then... etc
>>>
>
> But it is just as boring to write code where you have to check all the
> exceptions.  Often I see people using StrToInt without checking that it
> was a success.  TryStrToInt allows you to avoid exceptions, so if
> exceptions are so good, why do people use trystrtoint and why did borland
> create it if delphi is supposed to handle things the exception way? I
> think sometimes checking for errors makes the code easier to direct..
> except forces you to put the code as if you are using a GOTO except label.

But you do not need test all Exception types.
In 95% of time, in private methods, I just use try-except on e:
Exception do <something> end.

>> No, I mean is better use try-except than nested IFs/GOTO/etc.
>
> Exceptions are actually GOTO labels.. if you think about what is
> happening. If there are any exceptions what happens in your code? You GOTO
> the exception area.

Ok, I agree with that similarity, but you forgot one thing:
And if the programmer do not test all own functions? The program could
be broke, right? Using Exceptions and have a global try-except (ie
OnException application or something like that) you can finalize your
program better, don't agree?

>> Thanks for the tips... but, IMHO, the code above would be more simpler
>> like that:
>>
>> begin
>>     Result := False; // Success flag
>>     [...]
>>     procOne;
>>     procTwo;
>>     procThree;
>>     [...]
>>     Result := True;
>>   except
>>      on e: Exception do
>>        ShowMessage(e.Message);
>>   end;
>> end;
>>
>> Marcos Douglas
>
>
> But that just a goto statement going to the except label.. Exceptions in a
> way are actually forcing you to write your code in  a GOTO way.
>
> Often you want to handle errors differently, your above code sends it all
> to the GOTO except area.. but what if you have to clean up things
> depending on the situation? free memory, etc. It's often never as simple
> as going to the exception area. It seems easier on the surface to use
> exceptions, but when you look into it, it's often not as simple as writing
> all code to GOTO exception area...

Well, we can simplify using less Exceptions type.
Maybe, as I said before, one Exception type to each class would be
simpler than use many Exceptions. This class only will raise one type
of Exception and catch all others in private, ie, all public methods
should be a try-except and, if catch something, just re-raise the
Exception using the Exception of this class. Well, just a thought...

> Is the above code an exception or an error that you are catching? are
> errors and exceptions the same thing? Once again, IMO this whole subject
> needs to be researched more (academically too). What is the difference,
> precisely and rigorously, between an error and exception?  Are exceptions
> errors?  If so, why do some people say only to throw an exception when it
> is an exception, and use errors for other cases? If that is the case,
> exceptions cannot be the same as errors.

+1

> In Java exceptions and errors are the same thing, and/or the water is
> muddy and it is not clearly defined. In Delphi the water is muddy.  Often
> I see people using TryStrToInt instead of StrToInt, which means that
> people actually prefer checking the error (false or true) instead of
> checking the exception.

I see more StrToInt than TryStrToInt, definitely.

> Another interesting article is:
> http://www.joelonsoftware.com/items/2003/10/13.html

Very interesting and I agree when he say:
"I think the reason programmers in C/C++/Java style languages have
been attracted to exceptions is simply because the syntax does not
have a concise way to call a function that returns multiple values, so
it's hard to write a function that either produces a return value or
returns an error."

If we could return more than one value, ok we (maybe) do not need Exceptions.

Marcos Douglas