From: Didier G. M. <did...@og...> - 2005-08-28 04:11:11
|
Hello, on first run I had a nasty error message i/o error regarding the configuration file that could not be found, then after closing that message a friendly one that said that it was normal for 1st time user. Anyway the nasty message could disappear ? Didier Mandrake 10.1/fb 1.5/fr 0.3.1 |
From: Michael H. <mic...@el...> - 2005-08-30 07:45:14
|
Nando, Nando Dessena wrote: > I have done it in several places, but in the MIPFrame it exposed a > weird behaviour: loadPage() is actually called twice each time, which > means that any message displayed there gets displayed twice. for the time being there may be several such problems, as I have added the Subject::needsNotifyObjectsM member, so unlockSubject() may update a second time. This needs to be fixed with adding of lockSubject() and unlockSubject() and implementation of recursive locking. Once this is done it should actually improve update speed in FR, and eliminate such double updates. > AFAIR we support platforms that don't play well with exceptions so we > have to resort to more primitive error handling techniques. Is that > still true? More on that later, need to rush to a customer... Thanks -- Michael Hieke |
From: Nando D. <na...@de...> - 2005-08-30 08:09:51
|
Michael, >> I have done it in several places, but in the MIPFrame it exposed a >> weird behaviour: loadPage() is actually called twice each time, which >> means that any message displayed there gets displayed twice. MH> for the time being there may be several such problems, as I have added MH> the Subject::needsNotifyObjectsM member, so unlockSubject() may update a MH> second time. This needs to be fixed with adding of lockSubject() and MH> unlockSubject() and implementation of recursive locking. Once this is MH> done it should actually improve update speed in FR, and eliminate such MH> double updates. OK, I'll look in that direction then. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Michael H. <mic...@el...> - 2005-08-30 14:15:24
|
Nando, Nando Dessena wrote: >> The only thing that must not happen is the propagation of >> exceptions outside of our top-level functions and methods. > > Do you mean the event handlers? What else? Any wxWidgets methods that are overridden, like FRApp::OnInit(), and event handlers. > From a practical standpoint, I am simply mostly no longer unable to > design an error reporting mechanism without exceptions. :-( You are mostly no longer unable to? Umm, you would like to use them, or not? > We can just say that we only support those newer versions then. I use 2.3.5.0, and there it's the old stuff. Is there a newer one yet? Thanks -- Michael Hieke |
From: Nando D. <na...@de...> - 2005-08-30 14:20:04
|
Michael, >>> The only thing that must not happen is the propagation of >>> exceptions outside of our top-level functions and methods. >> >> Do you mean the event handlers? What else? MH> Any wxWidgets methods that are overridden, like FRApp::OnInit(), and MH> event handlers. OK. Not a small limitation, but probably one we can live with. >> From a practical standpoint, I am simply mostly no longer unable to >> design an error reporting mechanism without exceptions. :-( MH> You are mostly no longer unable to? Umm, you would like to use them, or MH> not? See what happens when you write several things at once? :-( "no longer able", that's what I meant. >> We can just say that we only support those newer versions then. MH> I use 2.3.5.0, and there it's the old stuff. Is there a newer one yet? Olivier? Ciao -- Nando Dessena http://www.flamerobin.org |
From: Milan B. <mi...@km...> - 2005-09-06 08:17:18
|
Nando Dessena wrote: > N> Does this: > > N> catch (...) { throw } > > N> retain the exception type for an outer handler or not? If so, then I > N> must be doing something wrong; if not, we're stuffed. > > I still can't find a definitive answer to this one. Can anyone help? Sorry, looks like I missed the message the first time. It does throw the current exception. For a good explanation and example look here: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9 -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-09-06 08:22:45
|
Milan, M> Nando Dessena wrote: >> N> Does this: >> >> N> catch (...) { throw } >> >> N> retain the exception type for an outer handler or not? If so, then I >> N> must be doing something wrong; if not, we're stuffed. >> >> I still can't find a definitive answer to this one. Can anyone help? M> Sorry, looks like I missed the message the first time. It does throw the M> current exception. this leaves the "something wrong on my part" path open. Or perhaps some wrong compiler switch in the FR project. I'll research more when I get back out for air next time. M> For a good explanation and example look here: M> http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9 Thanks! Nice site. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Milan B. <albis@EUnet.yu> - 2005-09-07 13:07:17
|
Nando Dessena wrote: > That's why it did compile. BTW, the reason why the compiler was > warning me about "non-executable code" apparently was that I was > mistakenly throwing exceptions by reference (throw new > exception("foo")); That's throwing by pointer. It would work if you would catch (exception *) but throwing by pointer is not recommended. AFAIK, there is no thing as throwing by reference in C++. You can (and probably should) catch by (preferably const) reference. If you catch by value it invokes the copy constructor on exception object (not necessarily a bad thing) -- Milan Babuskov http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-09-07 13:37:14
|
Milan, >> That's why it did compile. BTW, the reason why the compiler was >> warning me about "non-executable code" apparently was that I was >> mistakenly throwing exceptions by reference (throw new >> exception("foo")); MB> That's throwing by pointer. Yeah, yeah. Forgive the pointer/reference mixups of an old-time Delphee. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Milan B. <mi...@km...> - 2005-08-28 12:25:09
|
Didier Gasser Morlay wrote: > on first run I had a nasty error message i/o error regarding the > configuration file that could not be found, then after closing that > message a friendly one that said that it was normal for 1st time user. > > Mandrake 10.1/fb 1.5/fr 0.3.1 For the record, I've seen that one too. It's one of those wxWidgets' messages, and it really does look nasty (similar to Windows' crash report). I guess there might be some way to prevent it, but we first need to find a reliable way to reproduce it. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Michael H. <mic...@el...> - 2005-08-29 07:15:10
|
Milan, Milan Babuskov wrote: > For the record, I've seen that one too. It's one of those wxWidgets' > messages, and it really does look nasty (similar to Windows' crash > report). > > I guess there might be some way to prevent it, but we first need to > find a reliable way to reproduce it. we don't mostly pay attention to things that can go wrong. Right now we just do bool Root::load() { ifstream file(getFileName().c_str()); if (!file) return false; which will probaly call wxLogError() when there is a problem reading that file. To suppress these log messages one needs to set a new log target (redirect messages and handle them ourselves, or use wxLogNull to suppress them completely). The better way is to not try to open the file if it doesn't exist, which is what I did with showDocsHtmlFile(). We need to do the same for html templates, probably others too. Thanks -- Michael Hieke |
From: Milan B. <albis@EUnet.yu> - 2005-08-29 09:06:34
|
Michael Hieke wrote: > To suppress these log messages one needs to set a new log > target (redirect messages and handle them ourselves, or use wxLogNull to > suppress them completely). I figured that it's something like that. > The better way is to not try to open the > file if it doesn't exist, which is what I did with showDocsHtmlFile(). > We need to do the same for html templates, probably others too. Good idea. We'll do that. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-08-30 06:31:49
|
Milan, >> The better way is to not try to open the >> file if it doesn't exist, which is what I did with showDocsHtmlFile(). >> We need to do the same for html templates, probably others too. M> Good idea. We'll do that. I have done it in several places, but in the MIPFrame it exposed a weird behaviour: loadPage() is actually called twice each time, which means that any message displayed there gets displayed twice. I have then seen that the behaviour is already there in the CVS version, which displays a message if the file cannot be opened. Fixing that would require changing a host of void functions in the call chain to bool, but one of them cannot be changed because it's MetadataItemPropertiesFrame::update(). Another ugly fix would be to add a bool semaphor in MetadataItemPropertiesFrame::update() or MetadataItemPropertiesFrame::loadPage(), but I'm not sure. The proper fix of course would be to throw an exception in MetadataItemPropertiesFrame::loadPage() or MetadataItemPropertiesFrame::processHtmlFile(), but AFAIR we support platforms that don't play well with exceptions so we have to resort to more primitive error handling techniques. Is that still true? Any suggestion appreciated anyway. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Michael H. <mic...@el...> - 2005-08-30 12:15:09
|
Nando, Nando Dessena wrote: > The proper fix of course would be to throw an exception in > MetadataItemPropertiesFrame::loadPage() or > MetadataItemPropertiesFrame::processHtmlFile(), but AFAIR we support > platforms that don't play well with exceptions so we have to resort to > more primitive error handling techniques. Is that still true? > Any suggestion appreciated anyway. since we have to handle the exceptions that IBPP throws - it's probably safe to say that we can and should use them for error handling too. The only thing that must not happen is the propagation of exceptions outside of our top-level functions and methods. wxWidgets team has decided that exception safety in the library is too high a price to pay for users that don't use exceptions, and they also want to support compilers on systems that may not (completely) implement exception support. I believe the introduction of exceptions would greatly simplify a lot of code, and I'm all for it. The only question is what to do about IBPP, I believe that new versions base IBPP::Exception on std::exception while older do not. It's probably best to forbid the throwing of standard types like int and string, and to have catch (std::exception& e) { // ... } catch (...) { // ... } only in the top-level methods, so if we supported IBPP::Exception that is no std::exception we would need to catch and wrap those in code calling into IBPP. Thanks -- Michael Hieke |
From: Nando D. <na...@de...> - 2005-08-30 12:52:40
|
Michael, MH> since we have to handle the exceptions that IBPP throws - it's probably MH> safe to say that we can and should use them for error handling too. The MH> only thing that must not happen is the propagation of exceptions outside MH> of our top-level functions and methods. Do you mean the event handlers? What else? MH> I believe the introduction of exceptions would greatly simplify a lot of MH> code, and I'm all for it. From=20a practical standpoint, I am simply mostly no longer unable to design an error reporting mechanism without exceptions. :-( MH> The only question is what to do about IBPP, I MH> believe that new versions base IBPP::Exception on std::exception while MH> older do not. We can just say that we only support those newer versions then. Ciao --=20 Nando Dessena http://www.flamerobin.org |
From: Olivier M. <om-...@ti...> - 2005-09-01 13:37:07
|
On 30/08/2005 14:49 GMT+1, Nando Dessena wrote: > MH> The only question is what to do about IBPP, I > MH> believe that new versions base IBPP::Exception on std::exception while > MH> older do not. > > We can just say that we only support those newer versions then. IBPP 2.4 code base has exceptions based on std::exception for months, and it will be "released" very soon now. No real reason to delay it anymore. You very well could base FR on the current "beta" of IBPP 2.4. -- Olivier Mascia |
From: Milan B. <albis@EUnet.yu> - 2005-08-30 14:00:53
|
Nando Dessena wrote: > The proper fix of course would be to throw an exception in > MetadataItemPropertiesFrame::loadPage() or > MetadataItemPropertiesFrame::processHtmlFile(), but AFAIR we support > platforms that don't play well with exceptions so we have to resort to > more primitive error handling techniques. Is that still true? If you "throw" and "catch" the exception yourself, then there is no problem. That works flawlessly. The problem are "unexpected" exceptions we were trying to catch with some general handler, but that's quite different story. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-08-30 14:16:38
|
Milan, MB> If you "throw" and "catch" the exception yourself, then there is no MB> problem. even if I throw it in Root::something() and catch it in the global handler. MB> That works flawlessly. The problem are "unexpected" exceptions MB> we were trying to catch with some general handler, but that's quite MB> different story. Please define "unexpected". My memory is foggy. :-( Ciao -- Nando Dessena http://www.flamerobin.org |
From: Milan B. <albis@EUnet.yu> - 2005-08-30 14:37:14
|
Nando Dessena wrote: > MB> If you "throw" and "catch" the exception yourself, then there is no > MB> problem. > > even if I throw it in Root::something() and catch it in the global > handler. I believe so. > MB> That works flawlessly. The problem are "unexpected" exceptions > MB> we were trying to catch with some general handler, but that's quite > MB> different story. > > Please define "unexpected". My memory is foggy. :-( We had FR crash randonly, mostly when some code tried to use method of pointer to object which isn't there anymore. Coupled with wx's event handlers it could provide a nice mis-catches. Anyway, it currently seems to work just fine on all compilers. Only Borland has the issue that it only manages to catch the exception once, on second throw it simply exists the program. To conclude: fell free to use exceptions as error handling mechanism. As long as you do it in a "planned" fashion, no problem. -- Milan Babuskov http://fbexport.sourceforge.net http://www.flamerobin.org |
From: Michael H. <mic...@el...> - 2005-08-30 15:15:07
|
Milan, Nando, Milan Babuskov wrote: >> MB> If you "throw" and "catch" the exception yourself, then there >> MB> is no problem. >> >> even if I throw it in Root::something() and catch it in the global >> handler. > > I believe so. ATM we do not have a global handler. We have FRApp::OnFatalException(), which only handles exceptions that escape the global handler, which seems to be OnExceptionInMainLoop(). Did someone ever try that? Thanks -- Michael Hieke |
From: Nando D. <na...@de...> - 2005-08-30 15:28:57
|
Michael, MH> ATM we do not have a global handler. We have FRApp::OnFatalException(), MH> which only handles exceptions that escape the global handler, which MH> seems to be OnExceptionInMainLoop(). Did someone ever try that? no, that name doesn't ring any bell. But at one time we had a handler that restarted the main loop in case of exceptions, IIRC. I can't find traces of that code anymore. When I get home I'll search the archives. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Michael H. <mic...@el...> - 2005-08-30 15:45:11
|
Nando, Nando Dessena wrote: > no, that name doesn't ring any bell. But at one time we had a handler > that restarted the main loop in case of exceptions, IIRC. I can't > find traces of that code anymore. When I get home I'll search the > archives. that would be FRApp::OnFatalException(): void FRApp::OnFatalException() { if (wxYES == ::wxMessageBox([stuff removed])) { MainLoop(); } } But restarting MainLoop() that way is a hack, not a solution. Better to not leave the message loop at all. Maybe that's what OnExceptionInMainLoop() would give us... Thanks -- Michael Hieke |
From: Nando D. <na...@de...> - 2005-08-30 17:01:46
|
Michael, >> no, that name doesn't ring any bell. But at one time we had a handler >> that restarted the main loop in case of exceptions, IIRC. I can't >> find traces of that code anymore. When I get home I'll search the >> archives. M> that would be FRApp::OnFatalException(): M> void FRApp::OnFatalException() M> { M> if (wxYES == ::wxMessageBox([stuff removed])) M> { M> MainLoop(); M> } M> } No; here's what we had: int FRApp::OnRun() { while (true) { try { return wxApp::OnRun(); } catch (std::exception& e) { wxMessageBox(e.what(), _("std::exception catched."), wxOK | wxICON_ERROR); } catch (...) { OnFatalException(); } } } (with or without the outer while loop). M> But restarting MainLoop() that way is a hack, not a solution. Better to M> not leave the message loop at all. Maybe that's what M> OnExceptionInMainLoop() would give us... I have played a bit with OnExceptionInMainLoop, OnUnhandledException, OnFatalException, and in all cases the flow on control goes to OnFatalException due to the "catch (...)" block in the code above. IOW the exception type information is lost whatever I do. I have seen a bunch of "catch (...)" blocks in wx's code. Does this: catch (...) { throw } retain the exception type for an outer handler or not? If so, then I must be doing something wrong; if not, we're stuffed. Ciao -- Nando Dessena http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-08-31 06:08:37
|
I wrote: N> I have played a bit with OnExceptionInMainLoop, OnUnhandledException, N> OnFatalException, and in all cases the flow on control goes to N> OnFatalException due to the "catch (...)" block in the code above. furthermore, in the Unicode builds the compiler marks my throw statements as "non-executable code". Is that a matter of compiler options? Ciao -- Nando Dessena http://www.flamerobin.org |
From: Nando D. <na...@de...> - 2005-08-31 06:16:28
|
I wrote: N> furthermore, in the Unicode builds the compiler marks my throw N> statements as "non-executable code". Is that a matter of compiler N> options? well, not all throw statements actually. Just those in the form: wxString msg = ... throw new std::exception(wx2std(msg).c_str()); and not just in Unicode builds, but all the time (I was mislead by some other error in my code). AFAIU the wx2std() call is optional in ANSI builds and required in Unicode builds; when I put it in, the code becomes non-executable according to the compiler. I'm puzzled... Ciao -- Nando Dessena http://www.flamerobin.org |