comp.lang.ada
 help / color / mirror / Atom feed
* Re: Exception Handling within Gtkada
       [not found] <nnd$672ea4c3$361caa01@549d065034cf3e10>
@ 2021-09-21  6:49 ` Vadim Godunko
  2021-09-21  7:01   ` Dmitry A. Kazakov
  0 siblings, 1 reply; 6+ messages in thread
From: Vadim Godunko @ 2021-09-21  6:49 UTC (permalink / raw)


On Monday, September 20, 2021 at 3:06:02 PM UTC+3, ldries46 wrote:
> I want an exception to be seen within an existing window of Gtkada to be able to see details of the error. So I used:
> 
> exception
> when no_const =>
> Main_Window.Buffer.Insert_At_Cursor
> ("-------------------------------------------------------------------------"
> & To_String(CRLF));
> Main_Window.Buffer.Insert_At_Cursor("Error : io_const" & to_String(CRLF));
> end Test_Exception;
> 
> In this case the the program ends and the reason of the exception is lost. I want this only for a selected nr of exceptions. In this case the exception no_const.

Generally, Ada exceptions must not left scope of callback function. Thus, such code should be added to each callback/event handler/etc. subprogram of your application.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Exception Handling within Gtkada
  2021-09-21  6:49 ` Exception Handling within Gtkada Vadim Godunko
@ 2021-09-21  7:01   ` Dmitry A. Kazakov
  2021-09-21  7:24     ` Emmanuel Briot
  2021-09-22  8:42     ` ldries46
  0 siblings, 2 replies; 6+ messages in thread
From: Dmitry A. Kazakov @ 2021-09-21  7:01 UTC (permalink / raw)


On 2021-09-21 08:49, Vadim Godunko wrote:
> On Monday, September 20, 2021 at 3:06:02 PM UTC+3, ldries46 wrote:
>> I want an exception to be seen within an existing window of Gtkada to be able to see details of the error. So I used:
>>
>> exception
>> when no_const =>
>> Main_Window.Buffer.Insert_At_Cursor
>> ("-------------------------------------------------------------------------"
>> & To_String(CRLF));
>> Main_Window.Buffer.Insert_At_Cursor("Error : io_const" & to_String(CRLF));
>> end Test_Exception;
>>
>> In this case the the program ends and the reason of the exception is lost. I want this only for a selected nr of exceptions. In this case the exception no_const.
> 
> Generally, Ada exceptions must not left scope of callback function. Thus, such code should be added to each callback/event handler/etc. subprogram of your application.

Right. Each handler should end like this:

    exception
       when Error : others =>
          Glib.Message.Log
          (  "My fancy program",
             Log_Level_Critical,
             (  "Fault in On_Button_Click: "
             &  Exception_Information (Error)
          )  );
    end On_Button_Click;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Exception Handling within Gtkada
  2021-09-21  7:01   ` Dmitry A. Kazakov
@ 2021-09-21  7:24     ` Emmanuel Briot
  2021-09-21  7:40       ` Dmitry A. Kazakov
  2021-09-22  8:42     ` ldries46
  1 sibling, 1 reply; 6+ messages in thread
From: Emmanuel Briot @ 2021-09-21  7:24 UTC (permalink / raw)


> > Generally, Ada exceptions must not left scope of callback function. Thus, such code should be added to each callback/event handler/etc. subprogram of your application.
> Right. Each handler should end like this: 

We were talking the other day of the high-level Connect subprograms generated by GtkAda (`Gtk.Button.On_Clicked` and so on). Those will always catch exceptions and avoid propagating them to the C layer in gtk+ (which as Dmitry mentions is dangerous). They will in effect call `GtkAda.Bindings.Process_Exception`, which in turns calls a user-defined subprogram, see GtkAda.Bindings.Set_On_Exceptions

I think this should be the recommended approach for general exceptions. Of course, your callbacks should directly handle exceptions that they know how to recover from, and deal with that locally.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Exception Handling within Gtkada
  2021-09-21  7:24     ` Emmanuel Briot
@ 2021-09-21  7:40       ` Dmitry A. Kazakov
  0 siblings, 0 replies; 6+ messages in thread
From: Dmitry A. Kazakov @ 2021-09-21  7:40 UTC (permalink / raw)


On 2021-09-21 09:24, Emmanuel Briot wrote:
>>> Generally, Ada exceptions must not left scope of callback function. Thus, such code should be added to each callback/event handler/etc. subprogram of your application.
>> Right. Each handler should end like this:
> 
> We were talking the other day of the high-level Connect subprograms generated by GtkAda (`Gtk.Button.On_Clicked` and so on). Those will always catch exceptions and avoid propagating them to the C layer in gtk+ (which as Dmitry mentions is dangerous). They will in effect call `GtkAda.Bindings.Process_Exception`, which in turns calls a user-defined subprogram, see GtkAda.Bindings.Set_On_Exceptions

Very cool.

> I think this should be the recommended approach for general exceptions. Of course, your callbacks should directly handle exceptions that they know how to recover from, and deal with that locally.

Yes, but Ada does that much better. I mean rendezvous, which is Ada's 
idea of an event handling. An exception in a rendezvous propagates to 
the caller. For a GUI it would mean that if a callback fails the emitter 
of the signal gets an exception, which would be the right place to 
handle the issue rather than sweeping it under the rug.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Exception Handling within Gtkada
  2021-09-21  7:01   ` Dmitry A. Kazakov
  2021-09-21  7:24     ` Emmanuel Briot
@ 2021-09-22  8:42     ` ldries46
  2021-09-22 10:22       ` Dmitry A. Kazakov
  1 sibling, 1 reply; 6+ messages in thread
From: ldries46 @ 2021-09-22  8:42 UTC (permalink / raw)


Op 21-9-2021 om 9:01 schreef Dmitry A. Kazakov:
> On 2021-09-21 08:49, Vadim Godunko wrote:
>> On Monday, September 20, 2021 at 3:06:02 PM UTC+3, ldries46 wrote:
>>> I want an exception to be seen within an existing window of Gtkada 
>>> to be able to see details of the error. So I used:
>>>
>>> exception
>>> when no_const =>
>>> Main_Window.Buffer.Insert_At_Cursor
>>> ("-------------------------------------------------------------------------" 
>>>
>>> & To_String(CRLF));
>>> Main_Window.Buffer.Insert_At_Cursor("Error : io_const" & 
>>> to_String(CRLF));
>>> end Test_Exception;
>>>
>>> In this case the the program ends and the reason of the exception is 
>>> lost. I want this only for a selected nr of exceptions. In this case 
>>> the exception no_const.
>>
>> Generally, Ada exceptions must not left scope of callback function. 
>> Thus, such code should be added to each callback/event handler/etc. 
>> subprogram of your application.
>
> Right. Each handler should end like this:
>
>    exception
>       when Error : others =>
>          Glib.Message.Log
>          (  "My fancy program",
>             Log_Level_Critical,
>             (  "Fault in On_Button_Click: "
>             &  Exception_Information (Error)
>          )  );
>    end On_Button_Click;
>
I tried different approaches but they cannot solve my problem. Part of 
the problem is probably that I am developing a package which should be 
usable in all different kind of programs maybe even under programs using 
all different kind of GUI's. That means that exception handling cannot 
always be done in the package but should be done in at least a package 
calling that problem. With this approach I tried to solve an earlier 
problem I asked about "Is there a way to see if a value is declared as a 
constant". I tried to solve that problem in a way that needed Exception 
handling during running to solve a design problem that could be made. I 
will need another way to go around that problem.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Exception Handling within Gtkada
  2021-09-22  8:42     ` ldries46
@ 2021-09-22 10:22       ` Dmitry A. Kazakov
  0 siblings, 0 replies; 6+ messages in thread
From: Dmitry A. Kazakov @ 2021-09-22 10:22 UTC (permalink / raw)


On 2021-09-22 10:42, ldries46 wrote:
> Op 21-9-2021 om 9:01 schreef Dmitry A. Kazakov:
>> On 2021-09-21 08:49, Vadim Godunko wrote:
>>> On Monday, September 20, 2021 at 3:06:02 PM UTC+3, ldries46 wrote:
>>>> I want an exception to be seen within an existing window of Gtkada 
>>>> to be able to see details of the error. So I used:
>>>>
>>>> exception
>>>> when no_const =>
>>>> Main_Window.Buffer.Insert_At_Cursor
>>>> ("-------------------------------------------------------------------------" 
>>>>
>>>> & To_String(CRLF));
>>>> Main_Window.Buffer.Insert_At_Cursor("Error : io_const" & 
>>>> to_String(CRLF));
>>>> end Test_Exception;
>>>>
>>>> In this case the the program ends and the reason of the exception is 
>>>> lost. I want this only for a selected nr of exceptions. In this case 
>>>> the exception no_const.
>>>
>>> Generally, Ada exceptions must not left scope of callback function. 
>>> Thus, such code should be added to each callback/event handler/etc. 
>>> subprogram of your application.
>>
>> Right. Each handler should end like this:
>>
>>    exception
>>       when Error : others =>
>>          Glib.Message.Log
>>          (  "My fancy program",
>>             Log_Level_Critical,
>>             (  "Fault in On_Button_Click: "
>>             &  Exception_Information (Error)
>>          )  );
>>    end On_Button_Click;
>>
> I tried different approaches but they cannot solve my problem. Part of 
> the problem is probably that I am developing a package which should be 
> usable in all different kind of programs maybe even under programs using 
> all different kind of GUI's.

You still may not propagate exceptions through C.

> That means that exception handling cannot 
> always be done in the package but should be done in at least a package 
> calling that problem. With this approach I tried to solve an earlier 
> problem I asked about "Is there a way to see if a value is declared as a 
> constant". I tried to solve that problem in a way that needed Exception 
> handling during running to solve a design problem that could be made. I 
> will need another way to go around that problem.

Posing a problem correctly is a half of solution.

Anyway, if you want to propagate exceptions through GTK, that is 
possible to do by marshaling and then re-raising occurrence. GtkAda 
contributions does this in the package Gtk.Main.Router. It also gives 
stack trace of the exception in a popup dialog. And it can show the 
location in GPS if that is running in the server mode.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-09-22 10:22 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <nnd$672ea4c3$361caa01@549d065034cf3e10>
2021-09-21  6:49 ` Exception Handling within Gtkada Vadim Godunko
2021-09-21  7:01   ` Dmitry A. Kazakov
2021-09-21  7:24     ` Emmanuel Briot
2021-09-21  7:40       ` Dmitry A. Kazakov
2021-09-22  8:42     ` ldries46
2021-09-22 10:22       ` Dmitry A. Kazakov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox