Recent

Author Topic: Please advice  (Read 12512 times)

rvk

  • Hero Member
  • *****
  • Posts: 6112
Re: Please advice
« Reply #30 on: October 21, 2017, 12:37:00 pm »
Nonsense. On E:Exception does nothing extra.
It does something but in mentioned example it's not used.
It creates a variable E with which you can read out E.Message etc. for the exception. But if you don't use the E variable you don't need the "on E: Exception" either.

Quote
You should re-raise if it is nort related to the database.
Are you sure? Have you tried it without.
My understanding and experience is that you DON'T need to re-raise if you don't handle it with "on E:".
See my previous post. If you don't handle the exception in an "on E:" part the exception remains and it passed to the caller.
Code: Pascal  [Select][+][-]
  1. except
  2.   on E:EDatabaseError do // <-- less silly code. TDbf can raise this
  3.   begin
  4.     setlength(FieldsArray,0);
  5.   end;
  6.   // all other exception will fall through to the caller
  7. end;
You even get an error message if you try to re-raise outside of an "on E:" clause.

So you can't even re-raise in this example  >:D
« Last Edit: October 21, 2017, 12:39:42 pm by rvk »

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Please advice
« Reply #31 on: October 21, 2017, 12:52:42 pm »
Thaddy, it seems that you made the same mistake like me: not reading the entire thread...

It is the question how to make a function return a boolean result without raising an exception.
Database access, however, is a quite complex task, therefore, I think eating all exceptions is not a good idea here because the reason of a possible failure is hidden from the caller.

To be fair to Handoko he did not propose a boolean function, he merely asked the best way to get the field name information he was after while coping with any exceptions.
I introduced the idea of a boolean function.
In my experience exception handling is best left for library and low-level code. Most day-to-day programming does not need to check for exceptions because well-written library and system-related code already does that, and any exceptions higher level code encounters bubble up and identify themselves with an approriate error message.
You can protect users from the low-level gritty details of the error by eating the exception (not usually a good idea) or reflect the appearance of a problem in more general terms by having a boolean function to test as I suggested (and yes, its value should be initialised to False at the outset, which I failed to do).
In most cases I think the
  on E:Exception...
syntax is unnecessary in higher-level code, though of course it does have its uses.

I was completely wrong about TDataSet.Free not calling Close. Thanks for correcting that rvk, before the thread went too far in the wrong direction.
« Last Edit: October 21, 2017, 05:12:58 pm by howardpc »

munair

  • Hero Member
  • *****
  • Posts: 798
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: Please advice
« Reply #32 on: October 21, 2017, 12:53:08 pm »
It is the question how to make a function return a boolean result without raising an exception.
No, the OP simply asked how to intercept possible errors with his example code. howardpc came up with a simple function returning a boolean. Depending on what  the programmer prefers, both try..finally and try..except are valid solutions.

This thread should give enough information on how to do what the OP asked.

EDIT: it appears howardpc's last comment crossed mine.  ;D
« Last Edit: October 21, 2017, 01:01:29 pm by Munair »
keep it simple

Handoko

  • Hero Member
  • *****
  • Posts: 5131
  • My goal: build my own game engine using Lazarus
Re: Please advice
« Reply #33 on: November 28, 2017, 03:23:47 pm »
Quote from: Munair link=topic=38658.msg263473#msg263473
This thread should give enough information on how to do what the OP asked.
Yes, you're right. Very informative.

---

I admit using exception is not my strong skill, I know exception is good for error-recovery mechanisms. I'm maybe wrong but I use different approach. Before starting, I check all the possibilities that may fails the process. If something go wrong, I will show a 'friendly' message to the user and stop all the next steps below (using Exit). Exception's error-recovery mechanisms sounds good (for programmers) but I don't think users will like to know the technical things. For example I prefer to show "sorry, the process failed, please contact the programmer" instead of "division by zero".

So basically, I do not need to know what kind the exception is, because I do not try to recover the process. I prefer to let the programmer (me) to debug the program instead of adding exception codes into the program and to let users to deal with it.

But I should not be stubborn. I will try to use (more) exceptions in my codes in the future. I am glad that my simple question can attracted lots of advices and I can see the valid points of them.

I introduced the idea of a boolean function.
Me too often use this 'trick'. In this case this function does not return boolean value because I'm writing a simple program and the function to read database field names is not the main feature. So if it fails, it simply fails and shows nothing no need to be verbose.

In my experience exception handling is best left for library and low-level code.
Interesting. I write libraries more than 'full' programs. I should learn more about exceptions.

Thanks all for sharing your experiences with exceptions. Each times I read this thread I gain more understanding. I bookmarked this thread, will come back and implement them in my codes.

 

TinyPortal © 2005-2018