using exceptions

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

using exceptions

ik-6
Hello,

Exceptions like the name suggested, is to mark something that you are not suppose to expect.
For example while getting a data something went wrong, like disconnection, wrong size of data etc...

The usage of exception is very costly in performance, and there for should use only on specific events imho.

But we use exceptions even on places such as StrToInt, when the string is not an integer number, but we can expect to either have a number or something else. So why use an exception there ?

What do you think on this subject ? How would you choose when or where to use exceptions and why there ?

Ido

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marco van de Voort
In our previous episode, ik said:
> But we use exceptions even on places such as StrToInt, when the string is
> not an integer number, but we can expect to either have a number or
> something else. So why use an exception there ?

Because much used routines like strtoint are often used without proper
checking. So strtoint throws exceptions, and people that want to handle
errors properly use trystrtoint.
 
> What do you think on this subject ? How would you choose when or where to
> use exceptions and why there ?

Roughly the same as you. Few exceptions, and usually when in to abort fairly
deeply nested code.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marcos Douglas B. Santos
In reply to this post by ik-6
On Mon, Dec 19, 2011 at 4:53 PM, ik <[hidden email]> wrote:

> Hello,
>
> Exceptions like the name suggested, is to mark something that you are not
> suppose to expect.
> For example while getting a data something went wrong, like disconnection,
> wrong size of data etc...
>
> The usage of exception is very costly in performance, and there for should
> use only on specific events imho.
>
> But we use exceptions even on places such as StrToInt, when the string is
> not an integer number, but we can expect to either have a number or
> something else. So why use an exception there ?
>
> What do you think on this subject ? How would you choose when or where to
> use exceptions and why there ?

I use Exceptions to check the integrity of classes. I have one
Exception for each class (E<class_name>), most of the time.
I have Exceptions in 2 levels: user and Lib (API, business rules, etc).
If the Exception is in user level, the app do not aborts. But if the
Exception is in Lib level and the programmer did not catch, the app is
aborted.

I'm talkin bout Desktop apps. For Web applications the approach would
be different.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Bernd Kreuss
2011/12/19 Marcos Douglas <[hidden email]>:

>> The usage of exception is very costly in performance, and there for should
>> use only on specific events imho.

IMHO it has its legitimate uses. Thee are even languages (Python for
example) where it is considered totally normal to use exceptions all
over the place all the time, for example even every for loop will be
terminated (internally) by raising and catching an ent-of-iterator
exception, files raise an end-of-file exception, etc.

IMHO if you have something like

try
  foo := StrToInt(Argv[1]);
except
  // I don't care why exactly it fails
  foo := DEFAULT_FOO;
end;

then it makes the code much simpler and nothing can go wrong and also
I don't see any performance penalty here, it happens only once on
program start and not in a tight loop, in cases like this it is IMHO
totally ok.

It only becomes dangerous when you overuse it across larger and more
deeply nested parts of the code, for example where Classes might get
instantiated within the try and even more complicated is when
exceptions are allowed to happen in your constructors after it has
already constructed half (but not all) of its child objects, then you
have to take care that everything (even the incompletely constructed
objects) is properly destructed again,  this possibility can make your
destructors more complicated (or you are forced to use reference
counted interfaces for everything) and in the end the code won't get
simpler but more confusing instead.

Bernd
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

noreply
In reply to this post by ik-6
> Hello,
>
> Exceptions like the name suggested, is to mark something that you are not
> suppose to expect.
> For example while getting a data something went wrong, like disconnection,
> wrong size of data etc...
>
> The usage of exception is very costly in performance, and there for should
> use only on specific events imho.
>
> But we use exceptions even on places such as StrToInt, when the string is
> not an integer number, but we can expect to either have a number or
> something else. So why use an exception there ?
>
> What do you think on this subject ? How would you choose when or where to
> use exceptions and why there ?
>
> Ido

This is a difficult question that cost me many nights of sleep.

The TryStrToInt function is better than StrToInt for checking whether the
string is valid number. In this TryStrToInt function you just check for
TRUE or FALSE instead of exceptions. IF you look at the source code of
TryStrToInt in delphi, it just wraps the old Val() procedure.

So let me as this question.. why is it that TryStrToInt is useful if we
have exceptions? isn't it ambiguous to offer people two ways of doing the
same thing? answer: sometimes exceptions really aren't any cleaner than
using regular programming logic to check for errors.

Now another problem with exceptions is that you don't know for sure where
an exception will occur in code, whereas if someone ignores the error
return value, you can see it in the code that they have ignored it.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

noreply
In reply to this post by Marco van de Voort
> In our previous episode, ik said:
>> But we use exceptions even on places such as StrToInt, when the string
>> is
>> not an integer number, but we can expect to either have a number or
>> something else. So why use an exception there ?
>
> Because much used routines like strtoint are often used without proper
> checking. So strtoint throws exceptions, and people that want to handle
> errors properly use trystrtoint.

But why would they use trystrtoint when they could catch the exception
properly using an EXCEPT clause in the program?
Instead of checking for errors with trystrtoint, why not use exceptions
and then catch the exception? Well, for me I find exception code not to be
any clearer than TryStrToInt or Val()

>
>> What do you think on this subject ? How would you choose when or where
>> to
>> use exceptions and why there ?
>
> Roughly the same as you. Few exceptions, and usually when in to abort
> fairly
> deeply nested code.


There are exceptions all over lazarus and freepascal code, used as
errors.. the distinction between errors and exceptions is not clearly
defined, imo. They are used interchangbly.. even some of the exceptions
are called "ESomeError". So if they are errors, why are they exceptions?

Some people claim that exceptions are for extremely exceptional
circumstances and that errors are for all other cases.  However with Java
and Delphi it seems exceptions are actually errors, there is no
distinction. This needs to be academically researched more IMO.  The
Oberon developers have had intense discussions about it too, and yet
another word is used in oberon/component pascal... which is "TRAP".
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

noreply
In reply to this post by Marcos Douglas B. Santos
Marcos wrote:
> I use Exceptions to check the integrity of classes. I have one
> Exception for each class (E<class_name>), most of the time.


Another problem with errors is that sometimes it is hard for a class to
return errors. In procedural programming you can usually return an error
as a parameter but sometimes in class programming it is difficult for
classes to just return errors.

Exceptions are an attempt to solve the problem, but imo this still doesn't
solve all problems and our applications are full of wild exceptions going
off despite our attempts to solve the problem.. because people fail to
check exceptions and catch them. usually I see code like this:

Try

Finally


You don't see as much Try Except, it's more Try Finally. People ignore the
exceptions because it's an accepted thing to do. Then the end user of the
application gets a strange exception message instead of a user friendly
one. For example, if a file is not found, I like to give a polite "Cannot
find file" message.. but usually in delphi apps and examples all over the
newsgroups you see just an EFileNotFound exception pop up instead. Or,
with StrToInt, a similar obscure exception message to the end user instead
of a more friendly one.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marcos Douglas B. Santos
On Wed, Dec 21, 2011 at 10:29 PM,  <[hidden email]> wrote:
> Marcos wrote:
>> I use Exceptions to check the integrity of classes. I have one
>> Exception for each class (E<class_name>), most of the time.
>
>
> Another problem with errors is that sometimes it is hard for a class to
> return errors. In procedural programming you can usually return an error
> as a parameter but sometimes in class programming it is difficult for
> classes to just return errors.

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
error...  if error and error then... etc

> Exceptions are an attempt to solve the problem, but imo this still doesn't
> solve all problems and our applications are full of wild exceptions going
> off despite our attempts to solve the problem.. because people fail to
> check exceptions and catch them. usually I see code like this:
>
> Try
>
> Finally
>
>
> You don't see as much Try Except, it's more Try Finally. People ignore the
> exceptions because it's an accepted thing to do. Then the end user of the
> application gets a strange exception message instead of a user friendly
> one. For example, if a file is not found, I like to give a polite "Cannot
> find file" message.. but usually in delphi apps and examples all over the
> newsgroups you see just an EFileNotFound exception pop up instead. Or,
> with StrToInt, a similar obscure exception message to the end user instead
> of a more friendly one.

I use many try-except in my own code but, most of the time, just catch
my own exceptions because they are much more simpler to use. As I said
before, I have Exceptions in only 2 levels: user and Lib (API,
business rules, etc).
The User exceptions always show a user friendly message (I think that
you call Errors, right?). The Lib exceptions, for me, is the real
Exception. So, If I call a routine but the app is not connected on
DBMS... raise Exception; if a important property not been set... raise
Exception; if a file has not found, this is not a exception, but if
the app can not create a file... raise Exception.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Bart-48
In reply to this post by noreply
On 12/22/11, [hidden email] <[hidden email]> wrote:

> You don't see as much Try Except, it's more Try Finally. People ignore the
> exceptions because it's an accepted thing to do. Then the end user of the
> application gets a strange exception message instead of a user friendly
> one. For example, if a file is not found, I like to give a polite "Cannot
> find file" message.. but usually in delphi apps and examples all over the
> newsgroups you see just an EFileNotFound exception pop up instead. Or,
> with StrToInt, a similar obscure exception message to the end user instead
> of a more friendly one.

I tend to spend more time on catching errors and displaying user
friendly and useful error messages than I do on writing the core
functionality of most of my (simple) programs.

Bart
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Anton Shepelev
In reply to this post by Marcos Douglas B. Santos
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

If you mean having to write nested IFs to check  all
the  errors, then there are several ways to make the
error-checking in several calls "linearized":

    http://www.digipedia.pl/usenet/thread/1169/284/

I prefer using GOTO statements:

    begin
      Result := false; // Success flag
      [...]
      errMsg := errorOne;
      if not procOne  (...) then GOTO ERROR;
      errMsg := errTwo;
      if not procTwo  (...) then GOTO ERROR;
      errMsg := errThree;
      if not procThree(...) then GOTO ERROR;
      [...]
      Result := true
    ERROR:
    end

This way, the funtion returns an error  flag  and  a
correspoinding  message, and I prefer it to throwing
and catching Exceptions.   I  even  wrap  exception-
based  code  using external libraries in such proce-
dures to have an easier and cleaner error handling.

Also see:

    http://www.theregister.co.uk/2006/01/11/exception_handling/

Anton
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marcos Douglas B. Santos
On Thu, Dec 22, 2011 at 4:17 PM, Anton Shepelev <[hidden email]> 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
>
> If you mean having to write nested IFs to check  all
> the  errors, then there are several ways to make the
> error-checking in several calls "linearized":
>
>    http://www.digipedia.pl/usenet/thread/1169/284/

No, I mean is better use try-except than nested IFs/GOTO/etc.

> I prefer using GOTO statements:
>
>    begin
>      Result := false; // Success flag
>      [...]
>      errMsg := errorOne;
>      if not procOne  (...) then GOTO ERROR;
>      errMsg := errTwo;
>      if not procTwo  (...) then GOTO ERROR;
>      errMsg := errThree;
>      if not procThree(...) then GOTO ERROR;
>      [...]
>      Result := true
>    ERROR:
>    end
>
> This way, the funtion returns an error  flag  and  a
> correspoinding  message, and I prefer it to throwing
> and catching Exceptions.   I  even  wrap  exception-
> based  code  using external libraries in such proce-
> dures to have an easier and cleaner error handling.
>
> Also see:
>
>    http://www.theregister.co.uk/2006/01/11/exception_handling/

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

noreply
Marcos Douglas wrote:
> On Thu, Dec 22, 2011 at 4:17 PM, Anton Shepelev <[hidden email]>
> 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.

>
> 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.


>
> 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...

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.

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.

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


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marcos Douglas B. Santos
On Tue, Jan 3, 2012 at 7:20 PM, Lars <[hidden email]> wrote:

> Marcos Douglas wrote:
>> On Thu, Dec 22, 2011 at 4:17 PM, Anton Shepelev <[hidden email]>
>> 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

el_es
On 04/01/2012 00:31, Marcos Douglas wrote:
[...]

>> 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

I find myself often doing either:

function Bla(parameters): integer;
 - > returns => 0 for success/value returned, < 0 for error and upper layers recognize the error codes
(this is pretty much like c common usage you can find in c programs)
or
function Bla(some_params; out ErrorMessage: string):boolean;
or
function Bla(some_params; out ErrorCode: integer): some_type_other_than_integer;

so it's not like you /can't/ return more than one value...
but you need to prepare yourself for it ;)

L.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marcos Douglas B. Santos
On Wed, Jan 4, 2012 at 8:35 AM, Lukasz Sokol <[hidden email]> wrote:

>
> On 04/01/2012 00:31, Marcos Douglas wrote:
> [...]
> >> 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
>
> I find myself often doing either:
>
> function Bla(parameters): integer;
>  - > returns => 0 for success/value returned, < 0 for error and upper layers recognize the error codes
> (this is pretty much like c common usage you can find in c programs)
> or
> function Bla(some_params; out ErrorMessage: string):boolean;
> or
> function Bla(some_params; out ErrorCode: integer): some_type_other_than_integer;
>
> so it's not like you /can't/ return more than one value...
> but you need to prepare yourself for it ;)

Ok, I expressed myself poorly.
When I said: "If we could return more than one value, ok we (maybe) do
not need Exceptions."
I mean: "If we could return more than one value, using a better way
than 'out arguments' or 'array of const', ok we (maybe) do not need
Exceptions in many times".

I know we can use 'out args', 'array' or a object (this provides many
results) but this is not beautiful.
1- out args: we always have a local variable ErrorCode/ErrorMsg (like
your example) and this is boring.
2- array of const: we need 'unpack' the array; memleak could happen; etc;
3- object: we have a local variabel or use 'with' but memleak could
happen any way;

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

el_es
On 04/01/2012 11:50, Marcos Douglas wrote:

> Ok, I expressed myself poorly.
> When I said: "If we could return more than one value, ok we (maybe) do
> not need Exceptions."
> I mean: "If we could return more than one value, using a better way
> than 'out arguments' or 'array of const', ok we (maybe) do not need
> Exceptions in many times".
>
> I know we can use 'out args', 'array' or a object (this provides many
> results) but this is not beautiful.
> 1- out args: we always have a local variable ErrorCode/ErrorMsg (like
> your example) and this is boring.
> 2- array of const: we need 'unpack' the array; memleak could happen; etc;
> 3- object: we have a local variabel or use 'with' but memleak could
> happen any way;
>
> Marcos Douglas

You'd still need exceptions code to protect yourself from corner cases
(like data-(stream) dependent calculation that could possibly hit float div/0 for example)
because if you don't, your app will bail out...
otherwise e.g. your maths functions instead of /just/ doing what they need, will
have to check for possible misformed argument(s); and (IIIC - if I imagine correctly)
the exception catching code is closely paired to arithmetic errors like these;
also out-of-memory errors (may be ?) (which could explain the recommended everywhere
try-finally-end use case for most locally declared objects of e.g. TStringList type)

Object Pascal isn't 'C-plain'like where you'd need manual check for such cases and commonly
use 'goto error_label;' (common usage in Linux kernel AFAIS, go figure.)

C++ and Java also have underlying exception handling code.

IM(H)O you can't have a function return both a value (of whatever kind) and an error code without
seriously redefining language syntax.
Thing is, (most?) programming languages are based on math concept of a 'function' which is supposed
to return one meaningful value, where it's up to the upper layer to check for correctness of
arguments... either that or you check arguments and /abort/ function execution if they're bad.
And if the function return value is allowed -inf..0..+inf? you definitively need another out argument
to signal the upper layer something went wrong.

I see exception handling code/classes/objects as a globally (thread-safe?) accessible way of bailing out
from bad situation and telling the upper layer about it. It is effectively your way of 'returning
another value from function', if you look at it from a distance.

L.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marcos Douglas B. Santos
On Wed, Jan 4, 2012 at 9:18 AM, Lukasz Sokol <[hidden email]> wrote:

> On 04/01/2012 11:50, Marcos Douglas wrote:
>
>> Ok, I expressed myself poorly.
>> When I said: "If we could return more than one value, ok we (maybe) do
>> not need Exceptions."
>> I mean: "If we could return more than one value, using a better way
>> than 'out arguments' or 'array of const', ok we (maybe) do not need
>> Exceptions in many times".
>>
>> I know we can use 'out args', 'array' or a object (this provides many
>> results) but this is not beautiful.
>> 1- out args: we always have a local variable ErrorCode/ErrorMsg (like
>> your example) and this is boring.
>> 2- array of const: we need 'unpack' the array; memleak could happen; etc;
>> 3- object: we have a local variabel or use 'with' but memleak could
>> happen any way;
>>
>> Marcos Douglas
>
> You'd still need exceptions code to protect yourself from corner cases
> (like data-(stream) dependent calculation that could possibly hit float div/0 for example)
> because if you don't, your app will bail out...

Correct, because the language was designed that way.

> otherwise e.g. your maths functions instead of /just/ doing what they need, will
> have to check for possible misformed argument(s); and (IIIC - if I imagine correctly)
> the exception catching code is closely paired to arithmetic errors like these;
> also out-of-memory errors (may be ?) (which could explain the recommended everywhere
> try-finally-end use case for most locally declared objects of e.g. TStringList type)

Correct and try-finally is indispensable.

> Object Pascal isn't 'C-plain'like where you'd need manual check for such cases and commonly
> use 'goto error_label;' (common usage in Linux kernel AFAIS, go figure.)
>
> C++ and Java also have underlying exception handling code.
>
> IM(H)O you can't have a function return both a value (of whatever kind) and an error code without
> seriously redefining language syntax.
> Thing is, (most?) programming languages are based on math concept of a 'function' which is supposed
> to return one meaningful value, where it's up to the upper layer to check for correctness of
> arguments... either that or you check arguments and /abort/ function execution if they're bad.
> And if the function return value is allowed -inf..0..+inf? you definitively need another out argument
> to signal the upper layer something went wrong.
>
> I see exception handling code/classes/objects as a globally (thread-safe?) accessible way of bailing out
> from bad situation and telling the upper layer about it. It is effectively your way of 'returning
> another value from function', if you look at it from a distance.

I agree with you! But I was discussing the possibility do not using
Exceptions. ;-)
Another point is when and where uses Exceptions... that's what they
were discussing.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Bernd Kreuss
In reply to this post by noreply
2012/1/3 Lars <[hidden email]>:

> 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.

I would see Exceptions as being more like the fabled COMEFROM, the
legendary counterpart of the GOTO.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

el_es
In reply to this post by Marcos Douglas B. Santos
On 04/01/2012 12:47, Marcos Douglas wrote:

[i see I hit on the obvious so: cut]

>
> I agree with you! But I was discussing the possibility do not using
> Exceptions. ;-) Another point is when and where uses Exceptions...
> that's what they were discussing.
>
> Marcos Douglas

Well I think there is this choice:
- either do use exceptions and exception handling, thinking of it
as your way of /optionally/ implicitly returning error code from
inside a routine, i.e. your 'way to return another value from function'

- or (if possible by compiler switches) disable exception handling code
and handle all exceptions by hand. Or just don't use it, so it can be
optimized out. Implies that you have to be prepared for every corner case
in your error-paths as well.

As far as I see there is no third way. Or is there? :)

L.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: using exceptions

Marcos Douglas B. Santos
On Wed, Jan 4, 2012 at 9:56 AM, Lukasz Sokol <[hidden email]> wrote:

> On 04/01/2012 12:47, Marcos Douglas wrote:
>
> [i see I hit on the obvious so: cut]
>
>>
>> I agree with you! But I was discussing the possibility do not using
>> Exceptions. ;-) Another point is when and where uses Exceptions...
>> that's what they were discussing.
>>
>> Marcos Douglas
>
> Well I think there is this choice:
> - either do use exceptions and exception handling, thinking of it
> as your way of /optionally/ implicitly returning error code from
> inside a routine, i.e. your 'way to return another value from function'

That is the default way.

> - or (if possible by compiler switches) disable exception handling code
> and handle all exceptions by hand. Or just don't use it, so it can be
> optimized out. Implies that you have to be prepared for every corner case
> in your error-paths as well.

This is a good idea for code that needs extreme performance.
Even you use "ErrorCode returns" approach in your code, the RTL,
Lazarus, etc still use Exceptions and you have to live with they.

>
> As far as I see there is no third way. Or is there? :)

I guess not.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12