|
hi again
I saw in some code such thing :
(it was a mathematical formula parser)
try
{
...
}
catch(CException1 pError)
{
...
}
catch(CException2 pError)
{
...
}
catch(CException3 pError)
{
...
}catch(CException4 pError)
{
...
}
catch(CException5 pError)
{
...
}
catch(CException6 pError)
{
...
}
I have question : Is not it uncomfortable to write so many catches ? when all theses exceptions are some what related, could not we unite them under some CMainException class and catch only one exception ?
this code is from this article :
http://www.codeproject.com/cpp/VisualCalc.asp
From the Using the Code section
But the article is verry coool
-- modified at 4:15 Monday 29th May, 2006
|
|
|
|
|
Catch(...)
and then
GetLastError()
|
|
|
|
|
GetLastError will not help u in all cases.
it applicable if only if the library set the relevant errors
u may have to design ur own class if the exception is not provded by windows or the library u are using. if it is a generic one, then the code will be very less.
there are centralized and decentralized error handling strategy. select one which suits for u. if u r trying to reduce code, go for centralized one. but the common routine or class will be bulky because of this
SaRath
|
|
|
|
|
Aljechin wrote: GetLastError()
you can't get any error code or string using GetLastError if the Exception throwed is Custom!, GetLastError is Window specific api!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
In general catch(...) is bad form. There are exceptions such as when you do a catch all, perform some clean up and then re-throw, for example. A general rule of thumb with exception handling is that you should only catch what you expect to be thrown; a catch all violates this principle.
Steve
|
|
|
|
|
VisualCalc provides its own exception classes, so you will never get any accurate error message.
moreover, be careful of the case sensitivity of the language. Catch is not a valid keyword
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
big_denny_200 wrote: this code is from this article :
http://www.codeproject.com/cpp/VisualCalc.asp
It would be better if you ask the author of article directly, by posting your query at bottom of article only! anyways you can make a Base class CMainException <span style="color: Black;">and derived rest of class (i.e. CException1 ...) from them! and you can catch the any Exception in Base class Object</span>
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
ThatsAlok wrote: you can make a Base class CMainException and derived rest of class from them
like CVCalcParserException base class for example ?
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
toxcct wrote: ike CVCalcParserException base class for example ?
Thats why i asked him to post your problem in respective article Forum!,
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
It is better to catch exceptions by reference rather then by value as is in your sample code. i.e.
try
{
..
}
catch(const CException1 & Error)
{
...
}
First it's more efficient as no copying occurs. More importantly it avoids slicing and thus allows you to make a catch class with virtual functions. This is one way to avoid catching so many different exceptions types: instead you catch a base class with virtual functions by reference and make use of polymorphism.
Steve
|
|
|
|
|
Stephen Hewitt wrote: It is better to catch exceptions by reference rather then by value as is in your sample code
VisualCalc actually catches its exceptions by reference. the OP typed it wrong.
Stephen Hewitt wrote: it [...] allows you to make a catch class with virtual functions
exactly what it does...
Stephen Hewitt wrote: This is one way to avoid catching so many different exceptions types
it is also. actually, VisualCalc Parser provides a base class for all its exception classes, but i still catch each exception category one by one to provide a visual feedback to the calculator user... like this, he finally know if he did a syntax, mathematic of whatever kind of error in his expression...
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
hi denny,
why didn't you ask this at the bottom of the VisualCalc[^] article ? i would have asked immediately...
for your question, note that i don't catch the exceptions like you do (by copy : catch(CException1 pError) ) but by reference (catch(CException1& pError) ) which is trully different for the memory management.
about the many catch blocs, there's no problem with that. you can have as many catch as you like without altering the performances...
you can however reduce the number of catches (design matter) as i provide a base class for all the Parser exceptions (CVCAlcParserException class), but by doing this, you wouldn't be able to tell the user if he gets a syntax, a mathematic, or whatever kind of error...
that's all i think.
if you have any other questions, don't hesitate to ask on the article's message board
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
hi all
I saw this code :
inline int foo (char* pBuffer, const char* formatString) throw() {
assert (pBuffer);
assert (formatString);
return "something";
}
If i use this code and in Release build and pass pBuffer , whose value will be NULL, than I get a bug yes ? these asserts are useful only in debug mode, not ?
Is not it better to above this function like this :
inline int foo (char* buffer, const char* formatString) {
if(NULL == buffer)
throw someException();
if(NULL == formatString);
throw someOtherException();
return "something";
}
In this case if we catch the thrown exception than, we are secure in both Release ana Debug builds, not ?
so why use asserts and not throws ?
thank you
-- modified at 4:01 Monday 29th May, 2006
|
|
|
|
|
Programming errors are not exceptions. You can't remove bugs until and unless you fix them.
Once you have found and fixed all of the bugs,the assert macros are no longer necessary and you should turn them off by defining the NDEBUG macro.
Assertions show that you are still testing and debugging your code.
An exception is an unpredictable but expected event which cannot be prevented and must be handled.
Exceptions should be handled to the extent possible at the point where they are first detected.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: Once you have found and fixed all of the bugs
How can you know that you have eliminated all bugs ?
_AnShUmAn_ wrote: Assertions show that you are still testing and debugging your code
I see asserts in already posted codes...
_AnShUmAn_ wrote: An exception is an unpredictable but expected event
, why unpredictable.
Can not understang it fully
anyway thanks for reply
|
|
|
|
|
if the application is performing as per your expectations with no errors or CRASHES you should know that all the bugs are fixed. It's that simple.
So when you are done with this disable all ASSERTS by defining nDEBUG macro.
Exceptions are unpredictable because in some applications if many threads are running simultaneously than there may be a variable that would get modified in the other sections and cause an exception in another block but this is not guaranteed . It depends on the time the system allocates to each thread.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
asserts are using only for debug pupose.
suppose if ur buffer getting NULL a endless loop or a lengthy looop, u need not to debug the each loops.
if an assertion occrurs then it will show "This expression failed at this line of source code" then u can trace and correct the bug.
never put ur logic inside the assert macro. because it wont work in release build.
in release build VERIFY macro will satisfy u with the same functionality of assert offer.
I think asserts and exception standing at different areas of erro handling.
We are used to compare with strctured error handling and the normal error handling we are used to follow in "C".
it is depends on ur system to select which is suitable. each mechanism has its own advantages and disadvantages.
SaRath
|
|
|
|
|
I've got an app created as an ANSI Build and want to use a few controls such as an Edit control (CEdit) as Unicode, if running on Win2K or later. I don't want to build the app as Unicode at this time, as I want to support W98 and don't want to have to use the MS W98 Unicode Layer.
I've pretty much spent the day Google'ing and reading and it seems doable, but I've yet to find any concrete info on how. One idea is to provide my own implementation of CWnd::CreateEx() that calls CreateWindowExW() if we are running on W2K/XP etc. but I suspect there is more to it than that.
Has anyone done this or have any suggestions? Mucho thanks in advance.
Neville Franks, Author of Surfulater www.surfulater.com "Save what you Surf" and ED for Windows www.getsoft.com
|
|
|
|
|
If the app itself is unicode unaware, then how do you expect a child window of the app to handle unicode? You will have to do a unicode build to make the app work with unicode as far as I know.
Neville Franks wrote: it seems doable
In case if you did it, please post a reply here and I am very much interested to know how it is.
|
|
|
|
|
|
I am a begineer in VC++/MFC can I get some good samples or information links to start learning Multithreaded programming.
"No Defeat Is Final Until You Stop Trying"
|
|
|
|
|
Start here[^].
--
Roger
It's supposed to be hard, otherwise anybody could do it!
Regarding CodeProject: "resistance is pointless; you will be assimilated"
|
|
|
|
|
Scorpio wrote: I am a begineer in VC++/MFC can I get some good samples or information links to start learning Multithreaded programming.
What better than these samples...
MTGDI
MTMDI
MTRECALC
MUTEXES Search MSDN with these keywords to get the appropriate samples.
Nibu thomas
A Developer
Programming tips[^] My site[^]
|
|
|
|
|
Nibu thomas wrote: MTGDI
MTMDI
MTRECALC
MUTEXES
IMO, I never liked Threading Sample Provided by MSDN... The article by Mr Joseph, whoes link is mentioned by WhiteSky is one of the best article for learning multithreading programming.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
ThatsAlok wrote: IMO, I never liked Threading Sample Provided by MSDN...
I specially liked the sample MTGDI . These samples are a bit hard to understand but once you get a hang of it you are on a ball.
Nibu thomas
A Developer
Programming tips[^] My site[^]
|
|
|
|