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

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.

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

2011/12/19 Marcos Douglas :

> 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

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.

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

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

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.

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

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

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

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

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

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

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

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.

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?

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

+1

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

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

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.

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.

Correct, because the language was designed that way.

Correct and try-finally is indispensable.

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

2012/1/3 Lars :

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.

On 04/01/2012 12:47, Marcos Douglas wrote:

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

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.

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

http://en.wikipedia.org/wiki/COMEFROM

this is not a fabled or legendary construct... it actually does exist.

but I see exceptions rather like a 'trap' redirecting to fixed area ?

in quasi-linux-kernel-c:

if (unlikely(error(expression)) then goto except_area;

wrapping _every_ expression between try...except, (or try...finally too) (try...except only having a check: if no error, skip the except_area)

(by my thoughts and imaginations only)

L.

Hello FPC-Pascal,

Wednesday, January 4, 2012, 1:31:01 AM, you wrote:

MD> Very interesting and I agree when he say:
MD> "I think the reason programmers in C/C++/Java style languages have MD> been attracted to exceptions is simply because the syntax does not MD> have a concise way to call a function that returns multiple values, so MD> it's hard to write a function that either produces a return value or MD> returns an error."
MD> If we could return more than one value, ok we (maybe) do not need Exceptions.

No, because they are different concepts, an exception is a non expected error, this means that the code where the exception has been raised could or could not be anymore in a predictable state. Error are controlled, the code will remain stable or not, but that information is returned by the error code.

The example tryStrToInt can have an error code (expected and controlled) and one exception, which is an error that could not be reported as error, but produce a non stability situation.

tryStrToInt('ABCDEFGHIJKL') should return false;
tryStrToInt('12345678901234567890123456789012345678901234567890') can produce an exception, overflow, because the number is fine, it is a number, but it can not return the right value in 64 bits.

This is just an example, not a real situation.