How to ignore "Callback called exit"

[Dan Rawson]

I'd like to be able to ignore the "Callback called exit" warning (since I'm doing it on purpose <g>); how can I do it??

On a more general note, is there a mechanism (other than reading the source code) to determine what warnings categories
are actually available??

TIA . . . .

Dan

[Dominik Seelow]

Hello Dan,

> I'd like to be able to ignore the "Callback called exit" warning (since I'm doing it on purpose <g>); how can I do it??

That's presumeably not a warning but a fatal error?! They can be
trapped, but as the reason lies probably somewhere within your code, you
should rather try to fix the error.

>
> On a more general note, is there a mechanism (other than reading the source code) to determine what warnings categories
> are actually available??

You can set warnings and die messages at run-time. So you won't be able
to find out the message's text in advance:

for my $n (0..20){
warn ("I don't like this number $n\n") if rand($n)>10;
}

Or do you mean this:

form 'perldiag':

These messages are classified as follows (listed in increasing order of
desperation):

(W) A warning (optional).
(D) A deprecation (optional).
(S) A severe warning (default).
(F) A fatal error (trappable).
(P) An internal error you should never see (trappable).
(X) A very fatal error (nontrappable).
(A) An alien error message (not generated by Perl).

The majority of messages from the first three classifications above (W,
D & S) can be controlled using the warnings pragma.

HTH,
Dominik

[Dan Rawson]

Dominik Seelow wrote:

> Hello Dan,
>
>
>

>>I'd like to be able to ignore the "Callback called exit" warning (since I'm doing it on purpose <g>); how can I do it??

>
> That's presumeably not a warning but a fatal error?! They can be
> trapped, but as the reason lies probably somewhere within your code, you
> should rather try to fix the error.
>

>>On a more general note, is there a mechanism (other than reading the source code) to determine what warnings categories
>>are actually available??

>
>
> You can set warnings and die messages at run-time. So you won't be able
> to find out the message's text in advance:
>
> for my $n (0..20){
> warn ("I don't like this number $n\n") if rand($n)>10;
> }
>
> Or do you mean this:
>
> form 'perldiag':
>
> These messages are classified as follows (listed in increasing order of
> desperation):
>
> (W) A warning (optional).
> (D) A deprecation (optional).
> (S) A severe warning (default).
> (F) A fatal error (trappable).
> (P) An internal error you should never see (trappable).
> (X) A very fatal error (nontrappable).
> (A) An alien error message (not generated by Perl).
>
> The majority of messages from the first three classifications above (W,
> D & S) can be controlled using the warnings pragma.
>
> HTH,
> Dominik
>

Dominik -

Thanks; the error is listed as fatal in perldiag.

This is absolutely intentional in this case; I have a perl/Tk application which puts a directory selection dialog up at
startup. If they cancel on the initial dialog, the callback for the cancel button simply calls exit. On the other
hand, if they bring up the directory selection dialog after the app has started, then do a "Cancel", I simply return
them to the app without changing the directory selection.

With that said, I'm unclear about how I might trap this error . . . . I looked at perldiag, perlwarn, eval, die, etc
without much luck.

TIA . . .

Dan

[Dan Rawson]

Dan Rawson wrote:

> Dominik Seelow wrote:
>

>> Hello Dan,
>>
>>
>>

>>> I'd like to be able to ignore the "Callback called exit" warning
>>> (since I'm doing it on purpose <g>); how can I do it??

>>
>>
>> That's presumeably not a warning but a fatal error?! They can be
>> trapped, but as the reason lies probably somewhere within your code, you
>> should rather try to fix the error.
>>

>>> On a more general note, is there a mechanism (other than reading the
>>> source code) to determine what warnings categories are actually
>>> available??

>>
>>
>>
>> You can set warnings and die messages at run-time. So you won't be able
>> to find out the message's text in advance:
>>
>> for my $n (0..20){
>> warn ("I don't like this number $n\n") if rand($n)>10;
>> }
>>
>> Or do you mean this:
>>
>> form 'perldiag':
>>
>> These messages are classified as follows (listed in increasing order of
>> desperation):
>>
>> (W) A warning (optional).
>> (D) A deprecation (optional).
>> (S) A severe warning (default).
>> (F) A fatal error (trappable).
>> (P) An internal error you should never see (trappable).
>> (X) A very fatal error (nontrappable).
>> (A) An alien error message (not generated by Perl).
>>
>> The majority of messages from the first three classifications above (W,
>> D & S) can be controlled using the warnings pragma.
>>
>> HTH,
>> Dominik
>>

> Dominik -
>
> Thanks; the error is listed as fatal in perldiag.
>
> This is absolutely intentional in this case; I have a perl/Tk
> application which puts a directory selection dialog up at startup. If
> they cancel on the initial dialog, the callback for the cancel button
> simply calls exit. On the other hand, if they bring up the directory
> selection dialog after the app has started, then do a "Cancel", I simply
> return them to the app without changing the directory selection.
>
> With that said, I'm unclear about how I might trap this error . . . . I
> looked at perldiag, perlwarn, eval, die, etc without much luck.
>
> TIA . . .
>
> Dan
>

OK, I got it to work like this: from inside the tk callback sub-routine from the cancel button on the dialog:

if ($appRunning)
{
$dialogBox->destroy;
$mw->deiconify;
}
else
{
local $SIG{'__DIE__'};
exit 1;
}

Dan

[Steve Lidie]

Dan Rawson <daniel.rawson.take!this!out!@asml.nl> wrote:

> Dominik Seelow wrote:

>> Hello Dan,
>>
>>
>>

>>>I'd like to be able to ignore the "Callback called exit" warning (since I'm doing it on purpose <g>); how can I do it??

>>
>> That's presumeably not a warning but a fatal error?! They can be
>> trapped, but as the reason lies probably somewhere within your code, you
>> should rather try to fix the error.
>>

>>>On a more general note, is there a mechanism (other than reading the source code) to determine what warnings categories
>>>are actually available??

>>
>>
>> You can set warnings and die messages at run-time. So you won't be able
>> to find out the message's text in advance:
>>
>> for my $n (0..20){
>> warn ("I don't like this number $n\n") if rand($n)>10;
>> }
>>
>> Or do you mean this:
>>
>> form 'perldiag':
>>
>> These messages are classified as follows (listed in increasing order of
>> desperation):
>>
>> (W) A warning (optional).
>> (D) A deprecation (optional).
>> (S) A severe warning (default).
>> (F) A fatal error (trappable).
>> (P) An internal error you should never see (trappable).
>> (X) A very fatal error (nontrappable).
>> (A) An alien error message (not generated by Perl).
>>
>> The majority of messages from the first three classifications above (W,
>> D & S) can be controlled using the warnings pragma.
>>
>> HTH,
>> Dominik
>>

> Dominik -
>
> Thanks; the error is listed as fatal in perldiag.
>
> This is absolutely intentional in this case; I have a perl/Tk application which puts a directory selection dialog up at
> startup. If they cancel on the initial dialog, the callback for the cancel button simply calls exit. On the other
> hand, if they bring up the directory selection dialog after the app has started, then do a "Cancel", I simply return
> them to the app without changing the directory selection.
>
> With that said, I'm unclear about how I might trap this error . . . . I looked at perldiag, perlwarn, eval, die, etc
> without much luck.

ask in the proper group, that will help! (;

comp.lang.perl.tk

i haven't seen that error in years, perhaps your perl/tk is very old ...

>
> TIA . . .
>
> Dan
>
>
>
>

[Dan Rawson]

Steve Lidie wrote:

> Dan Rawson <daniel.rawson.take!this!out!@asml.nl> wrote:
>

>>Dominik Seelow wrote:
>>

>>>Hello Dan,
>>>
>>>
>>>
>>>
>>>>I'd like to be able to ignore the "Callback called exit" warning (since I'm doing it on purpose <g>); how can I do it??
>>>
>>>That's presumeably not a warning but a fatal error?! They can be
>>>trapped, but as the reason lies probably somewhere within your code, you
>>>should rather try to fix the error.
>>>
>>>
>>>>On a more general note, is there a mechanism (other than reading the source code) to determine what warnings categories
>>>>are actually available??
>>>
>>>
>>>You can set warnings and die messages at run-time. So you won't be able
>>>to find out the message's text in advance:
>>>
>>>for my $n (0..20){
>>> warn ("I don't like this number $n\n") if rand($n)>10;
>>>}
>>>
>>>Or do you mean this:
>>>
>>>form 'perldiag':
>>>
>>>These messages are classified as follows (listed in increasing order of
>>>desperation):
>>>
>>> (W) A warning (optional).
>>> (D) A deprecation (optional).
>>> (S) A severe warning (default).
>>> (F) A fatal error (trappable).
>>> (P) An internal error you should never see (trappable).
>>> (X) A very fatal error (nontrappable).
>>> (A) An alien error message (not generated by Perl).
>>>
>>>The majority of messages from the first three classifications above (W,
>>>D & S) can be controlled using the warnings pragma.
>>>
>>>HTH,
>>>Dominik
>>>

>>
>>Dominik -
>>
>>Thanks; the error is listed as fatal in perldiag.
>>
>>This is absolutely intentional in this case; I have a perl/Tk application which puts a directory selection dialog up at
>>startup. If they cancel on the initial dialog, the callback for the cancel button simply calls exit. On the other
>>hand, if they bring up the directory selection dialog after the app has started, then do a "Cancel", I simply return
>>them to the app without changing the directory selection.
>>
>>With that said, I'm unclear about how I might trap this error . . . . I looked at perldiag, perlwarn, eval, die, etc
>>without much luck.

>
>
> ask in the proper group, that will help! (;
>
> comp.lang.perl.tk
>
> i haven't seen that error in years, perhaps your perl/tk is very old ...
>
>
>

Steve -

It's 800.024 . . . .

Dan