Recent

Author Topic: Exceptions  (Read 5275 times)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Exceptions
« on: July 15, 2019, 05:39:36 pm »
Do you use them? I very rarely do. I do use try..except when needed, but often without anything in the except  :-[ I like to handle errors myself and gracefully close everything down if needed.

Half my code is testing values (all parameters, fields and globals used) and working around unexpected ones.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Exceptions
« Reply #1 on: July 15, 2019, 06:06:31 pm »
I use - in production code - exceptions, but only for  exceptions: unintended code paths or failures. With perfect programmers, perfect hardware and perfect compilers exceptions are nonsense, that is true.
Usually it is better to use errors. But almost nobody uses those  :o :( :(

I might add that I am a heavy user of asserts...
But exceptions are still a valid mechanism to protect users, not programmers:
Ever seen this?
Code: Pascal  [Select][+][-]
  1. try
  2.   // do something
  3. except
  4.  // if it fails do nothing.....
  5. end;.

Now, when I see such code I get really angry..... Happens all the time....
« Last Edit: July 15, 2019, 06:15:00 pm by Thaddy »
Specialize a type, not a var.

Handoko

  • Hero Member
  • *****
  • Posts: 5130
  • My goal: build my own game engine using Lazarus
Re: Exceptions
« Reply #2 on: July 15, 2019, 06:15:43 pm »
I rarely use exception. I always think all the possible errors that may happen and I handle them myself. I know what assertion is but I never use it.

I'm not a good programmer.  :-[

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Exceptions
« Reply #3 on: July 15, 2019, 06:21:18 pm »
I'm not a good programmer.  :-[
That's not true. :D
Specialize a type, not a var.

ASerge

  • Hero Member
  • *****
  • Posts: 2222
Re: Exceptions
« Reply #4 on: July 15, 2019, 06:35:57 pm »
Half my code is testing values (all parameters, fields and globals used) and working around unexpected ones.
Only if can get around it. For example in case of unexpected structure of external data (files, databases, responses from devices, etc) I raise an exception. Of course, this does not include cases where it can simply be ignored. Also when writing universal modules (used in more than one program).

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Exceptions
« Reply #5 on: July 15, 2019, 07:16:20 pm »
Apart from digging in the source code, how do you find out all the exceptions a call might raise?

Kays

  • Hero Member
  • *****
  • Posts: 569
  • Whasup!?
    • KaiBurghardt.de
Re: Exceptions
« Reply #6 on: July 15, 2019, 08:35:28 pm »
Apart from digging in the source code, how do you find out all the exceptions a call might raise?
Documentation.
Yours Sincerely
Kai Burghardt

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Exceptions
« Reply #7 on: July 15, 2019, 08:47:10 pm »
Apart from digging in the source code, how do you find out all the exceptions a call might raise?
Documentation.
In the general case you get libraries with/without documentation. Let's try with TFPHTTPClient.Get?

mas steindorff

  • Hero Member
  • *****
  • Posts: 532
Re: Exceptions
« Reply #8 on: July 15, 2019, 09:24:51 pm »
I use them whenever I use "outside" code, like any library call.  for example, format() is a function that can be tested and tested and then a strange value will sneak in and crash your program. 
windows 10 &11, Ubuntu 21+ - fpc 3.0.4, IDE 2.0 general releases

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Exceptions
« Reply #9 on: July 15, 2019, 09:42:23 pm »
I use try..except when calling a function/method that throws an exception when something goes wrong. It's one way to flag an error, I guess.

But that raises an interesting question: what makes something an error? Say, if I have to calculate something according to three user inputs, do I flag it as an error when one or two of those aren't filled?

I never determine up front what path my code is going to take. I try to have my code give its best effort according to the available inputs. Try to guess what the optimal response would be in each case.

Compared to simply raising an exception and aborting execution whenever the predetermined path cannot be followed, I think my programs encounter 1000+% less bugs. Simply because they do check and ponder.

Handoko

  • Hero Member
  • *****
  • Posts: 5130
  • My goal: build my own game engine using Lazarus
Re: Exceptions
« Reply #10 on: July 15, 2019, 10:23:28 pm »
I usually write code like this:

function MyFunction(val1, val2, ...): TOutput;
begin

 
// set the default output value
  Result := 0;

 
// make sure the inputs are valid
  if not(val1 valid) then Exit;
  if not(val2 valid) then Exit;

 
// do the process
  if somethingbad then Exit;
  Result := process output;

end;


I always avoid try..except block, I personally think it is not good to show that 'panic' message to users. In the old DOS days I use IOResult, now I use all the think I can to check if the process may go wrong.

I am okay to use try..finally block to free the object/memory if I perform some hardware operations, like disk operation. But I usually will check the existence of the target/source file, the free disk space, etc first before performing that 'dangerous' operation.

Maybe not the best, but that it is what I usually do.
« Last Edit: July 15, 2019, 10:32:20 pm by Handoko »

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Exceptions
« Reply #11 on: July 15, 2019, 10:55:44 pm »
You're halfway there  ;D

Just think if you could do something else useful instead of exiting.

VTwin

  • Hero Member
  • *****
  • Posts: 1215
  • Former Turbo Pascal 3 user
Re: Exceptions
« Reply #12 on: July 15, 2019, 11:31:24 pm »
I suppose I am similar to Handoko, his function returns 0 if there is a problem. Any needed user message can be sent after calling it. I try to keep error messages out of lower level functions.

I always test for division by zero, etc. I find the behavior is different on Mac and Win, Mac seems more accepting of nan than Win. Sometimes I find bugs only after testing on more than one platform.
“Talk is cheap. Show me the code.” -Linus Torvalds

Free Pascal Compiler 3.2.2
macOS 12.1: Lazarus 2.2.6 (64 bit Cocoa M1)
Ubuntu 18.04.3: Lazarus 2.2.6 (64 bit on VBox)
Windows 7 Pro SP1: Lazarus 2.2.6 (64 bit on VBox)

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Exceptions
« Reply #13 on: July 15, 2019, 11:42:23 pm »
What about operators?

Let's assume the following operator:
Code: Pascal  [Select][+][-]
  1. operator /(A,B:String):double;
  2. var
  3.   dA,dB: double;
  4.   iCode: integer;
  5. begin
  6.   Val(A, dA, iCode);
  7.   if iCode<>0 then Error;
  8.  
  9.   Val(B, dB, iCode);
  10.   if iCode<>0 then Error;
  11.  
  12.   Result := dA/dB;
  13. end;

How do you handle the Error above?
What about division by zero?

VTwin

  • Hero Member
  • *****
  • Posts: 1215
  • Former Turbo Pascal 3 user
Re: Exceptions
« Reply #14 on: July 16, 2019, 12:37:11 am »
What about operators?

Let's assume the following operator:
Code: Pascal  [Select][+][-]
  1. operator /(A,B:String):double;
  2. var
  3.   dA,dB: double;
  4.   iCode: integer;
  5. begin
  6.   Val(A, dA, iCode);
  7.   if iCode<>0 then Error;
  8.  
  9.   Val(B, dB, iCode);
  10.   if iCode<>0 then Error;
  11.  
  12.   Result := dA/dB;
  13. end;

How do you handle the Error above?
What about division by zero?

Good example, but I would not be comfortable using such a function. I have numerous functions to convert user strings to, and from, doubles, including including degrees or gradians as strings to radians, latitude and longitude strings (deg min sec, decimal deg, etc.) to radians, and other things, so check at that level (file, editbox, etc) for valid input. For division by zero, I check that Abs(b) > eps (such as 1e-9).

The closest is something like:

Code: Pascal  [Select][+][-]
  1. operator / (a: Matrix3; b: double) c: Matrix3;
  2. begin
  3.   result := Mul(a, 1.0/b);
  4. end;  

but I check b before calling. I'm not claiming it is the best way, it is just how I do things.
“Talk is cheap. Show me the code.” -Linus Torvalds

Free Pascal Compiler 3.2.2
macOS 12.1: Lazarus 2.2.6 (64 bit Cocoa M1)
Ubuntu 18.04.3: Lazarus 2.2.6 (64 bit on VBox)
Windows 7 Pro SP1: Lazarus 2.2.6 (64 bit on VBox)

 

TinyPortal © 2005-2018