forum.alglib.net

ALGLIB forum
It is currently Mon Dec 23, 2024 5:23 am

All times are UTC


Forum rules


1. This forum can be used for discussion of both ALGLIB-related and general numerical analysis questions
2. This forum is English-only - postings in other languages will be removed.



Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: catch(...)
PostPosted: Wed Aug 22, 2012 8:54 am 
Offline

Joined: Thu Jul 19, 2012 3:35 pm
Posts: 4
Hi,

The code of the pearsoncorr2 contains following try/catch block.

try
{
...
}
catch(alglib_impl::ae_error_type)
{
throw ap_error(_alglib_env_state.error_msg);
}
catch(...)
{
throw;
}

My program crashes in the last catch(...) clause .
What exceptions are to be catched by that catch(...) clause ?

Isn't be better to remove that clause at all?


Top
 Profile  
 
 Post subject: Re: catch(...)
PostPosted: Thu Aug 23, 2012 6:39 am 
Offline
Site Admin

Joined: Fri May 07, 2010 7:06 am
Posts: 927
What do you mean by "crashes in the last catch(...) clause"? Does it crash because of unhandled exception other than alglib_impl::ae_error_type? If so, can you post code which makes ALGLIB to crash? The only exception ALGLIB should throw under normal circumstances is alglib_impl::ae_error_type


Top
 Profile  
 
 Post subject: Re: catch(...)
PostPosted: Thu Aug 23, 2012 9:15 am 
Offline

Joined: Thu Jul 19, 2012 3:35 pm
Posts: 4
From one side that was my wrong interpritation of dump analysis showing me the "throw;" as the crash line, rather then as the *next* executable line code.
Sorry for misleading on that!

Indead my programm crashed while it did not handle alglib_impl::ap_error exception.

Anyway, I fill very unconfortable when I see the code like that :

catch(...)
{
throw;
}

and that:

double result = ...;
return *(reinterpret_cast<double*>(&result));


Top
 Profile  
 
 Post subject: Re: catch(...)
PostPosted: Thu Aug 23, 2012 10:45 am 
Offline
Site Admin

Joined: Fri May 07, 2010 7:06 am
Posts: 927
I agree with your opinion on catch(...), it will be removed in the next release. As for reinterpret_cast, it is necessary in some cases, and the whole code is automatically generated, so it was very easy just to include it anywhere, independently of whether it is actually needed or not. I will think on this issue, maybe it will be removed in "easy" cases.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group