Recent

Author Topic: Enabling "try" to handle errors rather than the debugger [SOLVED]  (Read 3430 times)

pascal111

  • Sr. Member
  • ****
  • Posts: 359
  • Un trabajo en equipo para programas serias.
Enabling "try" to handle errors rather than the debugger [SOLVED]
« on: September 09, 2021, 07:26:25 pm »
In this code, the Lazarus debugger doesn't allow "try" block to handle the error, the debugger is still handling the error, I want "try" to handle the error rather than the debugger:

Code: Pascal  [Select][+][-]
  1. program project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.  
  7.   {$IFDEF UNIX}{$IFDEF UseCThreads}
  8.   cthreads,
  9.   {$ENDIF}{$ENDIF}
  10.   Classes, Dialogs, sysutils, forms, LCLType, interfaces
  11.   { you can add units after this };
  12.  
  13. var
  14.   s:string;
  15.   i:integer;
  16.  
  17. begin
  18.  
  19.   s:='g';
  20.  
  21.   try
  22.   i:=strtoint(s);
  23.  
  24.   except
  25.     on EConvertError do
  26.     begin
  27.       showmessage('s has pure string value!');
  28.     end;
  29.   end;
  30.  
  31.  
  32.  
  33. end.
  34.  
  35.  
« Last Edit: September 09, 2021, 09:04:07 pm by pascal111 »

Warfley

  • Hero Member
  • *****
  • Posts: 557
Re: Enabling "try" to handle errors rather than the debugger
« Reply #1 on: September 09, 2021, 08:07:16 pm »
The debugger will notify you as soon as an exception is risen. If you then click continue it will go to the next except block (or crash the application if there is none).

If you don't want that notification, there is a checkbox in the popup window (Ignore this exception type), with which this popup will not come anymore for this type of exception

pascal111

  • Sr. Member
  • ****
  • Posts: 359
  • Un trabajo en equipo para programas serias.
Re: Enabling "try" to handle errors rather than the debugger
« Reply #2 on: September 09, 2021, 08:14:46 pm »
The debugger will notify you as soon as an exception is risen. If you then click continue it will go to the next except block (or crash the application if there is none).

If you don't want that notification, there is a checkbox in the popup window (Ignore this exception type), with which this popup will not come anymore for this type of exception

Good! so there's no compiler directive - for example - to disable the debugger auto-handling of the already handled exceptions by "try" block?

winni

  • Hero Member
  • *****
  • Posts: 2715
Re: Enabling "try" to handle errors rather than the debugger
« Reply #3 on: September 09, 2021, 08:19:07 pm »
Hi!

Just run your app outside the IDE.

Then you will see, that there is no debugger messages but only your showMessage.

And that is what you finally need:

A correct behaviour, when the app is not developed anymore but used outside the IDE.


Winni
« Last Edit: September 09, 2021, 08:25:20 pm by winni »

pascal111

  • Sr. Member
  • ****
  • Posts: 359
  • Un trabajo en equipo para programas serias.
Re: Enabling "try" to handle errors rather than the debugger
« Reply #4 on: September 09, 2021, 09:03:42 pm »
Hi!

Just run your app outside the IDE.

Then you will see, that there is no debugger messages but only your showMessage.

And that is what you finally need:

A correct behaviour, when the app is not developed anymore but used outside the IDE.


Winni

Wow! that's what I thought on my mind as if you are reading my mind! but I tried to gain new information not to make my knowledge limited in some basics.

Warfley

  • Hero Member
  • *****
  • Posts: 557
Re: Enabling "try" to handle errors rather than the debugger
« Reply #5 on: September 09, 2021, 09:20:27 pm »
Good! so there's no compiler directive - for example - to disable the debugger auto-handling of the already handled exceptions by "try" block?
I don't think so. I mean it's not really a compiler feature but an IDE feature so a compiler directive doesn't make much sense here.

pascal111

  • Sr. Member
  • ****
  • Posts: 359
  • Un trabajo en equipo para programas serias.
Re: Enabling "try" to handle errors rather than the debugger
« Reply #6 on: September 09, 2021, 09:50:31 pm »
Good! so there's no compiler directive - for example - to disable the debugger auto-handling of the already handled exceptions by "try" block?
I don't think so. I mean it's not really a compiler feature but an IDE feature so a compiler directive doesn't make much sense here.

Great! logical words!

winni

  • Hero Member
  • *****
  • Posts: 2715
Re: Enabling "try" to handle errors rather than the debugger [SOLVED]
« Reply #7 on: September 09, 2021, 10:07:12 pm »
Theory and practice ....

Just test it!

Tsss tsss tsss ...

Winni

pascal111

  • Sr. Member
  • ****
  • Posts: 359
  • Un trabajo en equipo para programas serias.
Re: Enabling "try" to handle errors rather than the debugger [SOLVED]
« Reply #8 on: September 09, 2021, 10:24:04 pm »
Theory and practice ....

Just test it!

Tsss tsss tsss ...

Winni

Maybe in this case due that there's no other solution, but in some other cases it's not a doable method.

winni

  • Hero Member
  • *****
  • Posts: 2715
Re: Enabling "try" to handle errors rather than the debugger [SOLVED]
« Reply #9 on: September 09, 2021, 11:05:07 pm »
Hi!

I don't get you.

Do you want to develop your whole live your app?

There might be a time that your app is ready and you don't need the IDE anymore and you can start to distribute it.  That is the normal way.

So get used to it.

Winni

pascal111

  • Sr. Member
  • ****
  • Posts: 359
  • Un trabajo en equipo para programas serias.
Re: Enabling "try" to handle errors rather than the debugger [SOLVED]
« Reply #10 on: September 10, 2021, 11:48:31 am »
Hi!

I don't get you.

Do you want to develop your whole live your app?


It seems I didn't get you too, I don't know this English structure.

Quote

There might be a time that your app is ready and you don't need the IDE anymore and you can start to distribute it.  That is the normal way.


Maybe you mean that I won't develop my program all my life, it won't consume all my time, I think you mean that.

Quote
So get used to it.

Winni

What this means? maybe my English is bad.

Warfley

  • Hero Member
  • *****
  • Posts: 557
Re: Enabling "try" to handle errors rather than the debugger [SOLVED]
« Reply #11 on: September 10, 2021, 01:24:18 pm »
There might be a time that your app is ready and you don't need the IDE anymore and you can start to distribute it.  That is the normal way.
So you say, if someone relies on try-except in their code they should just not use a debugger at all, because, at some point the software has to run without one anyway?
I see a tiny problem with this, what if you have to debug your code? Just not using the debugger is a completely non-solution to the problem at hand. Its not "either use try-except or use the debugger" you should be able to use both, maybe even to debug your except block...

This is IMHO a real inconvinience with the FPC/Lazarus environment. Exceptions are really useful, e.g. if you have a TCP stream, when it is closed most implementations (such as Indy) throw  an exception to notify the user about the stream being closed. This is not an error which needs to be fixed, but must simply be handled, e.g. by doing a reconnect. Having the debugger break every time such a thing happens can be really annoying.
Other language tools have solved this problem neatly. For C#, Java or Python the primary debuggers provide a feature to break only on uncought exceptions and exceptions that are cought by a try-except are simply handled by that. We only have the "Ignore exceptions of that type" option, while it is better than nothing it feels a bit like a nuklear option (even though, not as nuklear as simply not using the debugger at all). Just because I don't want to be notified on a certain ConvertError doesn't mean I don't want to be notified on all ConvertErrors, a context aware option would be much nicer.
That said, I think that this is simply a GDB problem and is not easiely solvable on the FPC and/or Lazarus side, so it's just something we have to live with.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7440
  • Debugger - SynEdit - and more
    • wiki
Re: Enabling "try" to handle errors rather than the debugger [SOLVED]
« Reply #12 on: September 10, 2021, 02:45:02 pm »
You currently have 2 options:

1) If there is an exception of type TExceptionStreamClosed then you can tell the debugger to ignore this exception.

2) If you did not tell the debugger to ignore it, then you can press F9 on such an exception and your app continues and handles the exception.

(And with the gdb backend, there is an option to ignore all exceptions...)




Other options are currently not available. Would be nice to have them, but someone needs to find the time to implement them.
Easy to implement options would be
- the text of the exception message
- the unit / function in which the exception was raised.

As for the mentioned "unhandled" exception... Well that is complicated.

First of all, depending on OS and fpc version the debugger may not even have access to the info if there is a try/except block.
In cases where this could be found it may require some effort. And even then, it only knows if there is a try block. It may or may not know if this is a finally or except block. And if it can find out that it is an except block it still has no way of knowing if it will handle a given exception class (i.e. if it has some "on E: TFooException" or not.
So there is no way to tell if an exception will be handled in the end or not.

ASerge

  • Hero Member
  • *****
  • Posts: 1871
Re: Enabling "try" to handle errors rather than the debugger
« Reply #13 on: September 11, 2021, 06:14:45 pm »
The debugger will notify you as soon as an exception is risen. If you then click continue it will go to the next except block (or crash the application if there is none).
Or in the "Project Options/Language Exceptions" turn off "Notify on Exceptions".

 

TinyPortal © 2005-2018