A question of indentation!
-
Daniel Turini wrote: thought that in PGP SDK a return value of false indicates an error condition. Well, I was talking in a general sense and didn't realize you were referring to the PGP SDK in particular. My bad.
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class ImplementationEddie Velasquez wrote: Well, I was talking in a general sense and didn't realize you were referring to the PGP SDK in particular. My bad. PGP calls return a PGPError and you need to call IsPGPError(...) on it to figure out whether it was an error or not. Some cases you actually get an error and it's not really an error overall! Like some encryption algorithms won't work when it's an RSA key but you are supposed to ignore that since it won't cause any problem Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
-
Christian Graus wrote: An exception does not necessarily mean an error. An exception should always indicate an error... that's why they're called "exceptions"... because they're exceptional. :) Or did I miss something in your post?
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class ImplementationEddie Velasquez wrote: An exception should always indicate an error... That's what I also thought. But PGP errors are often not errors. I have explained in one of the mis-placed posts here. I don't wanna re-type it :-) The indendation of this thread is now worse than any indentation I could have produced :-) Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
-
Eddie Velasquez wrote: That's why you should wrap up the API in C++ classes and let destructors take care of the cleanup. Yeah, I gotta do that. I really must! I am not a naturally OOPish guy, you know! Nish :-)
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
(Using my best Yoda voice...) Ummm. Strong in the force you are... but OOP you must.;)
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation -
Well, it seems that you need some kind of object wrapper over PGPError. The object could convert that to true/false or even throw some exception. Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?Tomasz Sowinski wrote: Well, it seems that you need some kind of object wrapper over PGPError. The object could convert that to true/false or even throw some exception Shucks! It always comes down to the basics and theory. If my OOP theory was strong enough I'd not have run into this situation :-( Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
-
Daniel Turini wrote: That's why exception handling was invented. Try throwing exceptions instead of nesting if's. Cool! I never thought of that! I just don't know much about exception handling though. What's this PGPException thing? Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
Nish - Native CPian wrote: What's this PGPException thing? A class you'd create to handle exceptions from PGP SDK. The best exception handling class I saw for an API is CWin32Error. Probably you don't need something so complicated, but some of Jadhav's ideas are pretty good and simple to implement. Crivo Automated Credit Assessment
-
Nish - Native CPian wrote: What's this PGPException thing? A class you'd create to handle exceptions from PGP SDK. The best exception handling class I saw for an API is CWin32Error. Probably you don't need something so complicated, but some of Jadhav's ideas are pretty good and simple to implement. Crivo Automated Credit Assessment
Daniel Turini wrote: A class you'd create to handle exceptions from PGP SDK. The best exception handling class I saw for an API is CWin32Error. Probably you don't need something so complicated, but some of Jadhav's ideas are pretty good and simple to implement. Thanks! I'll look it up. Nish :-)
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
-
Tomasz Sowinski wrote: Well, it seems that you need some kind of object wrapper over PGPError. The object could convert that to true/false or even throw some exception Shucks! It always comes down to the basics and theory. If my OOP theory was strong enough I'd not have run into this situation :-( Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
Post more code - especially, how PGPError is returned and when it means an error. Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans? -
Eddie Velasquez wrote: An exception should always indicate an error... That's what I also thought. But PGP errors are often not errors. I have explained in one of the mis-placed posts here. I don't wanna re-type it :-) The indendation of this thread is now worse than any indentation I could have produced :-) Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
Nish - Native CPian wrote: That's what I also thought. But PGP errors are often not errors. If a PGP error isn't a "real" error (informational return value) then it shouldn't raise an exception or you can catch the exception and just ignore it.
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation -
Christian Graus wrote: An exception does not necessarily mean an error. An exception should always indicate an error... that's why they're called "exceptions"... because they're exceptional. :) Or did I miss something in your post?
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class ImplementationTo quote Stroustrup: The Exception handling mechanism is a nonlocal control structure based on stack unwinding that can be seen as an alternative return mechanism. There are therefore legitimate uses of exceptions that have nothing to do with errors. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
-
Tomasz Sowinski wrote: if (call1() && call2() && call3() ....) That won;'t work. I am not supposed to call call-n unless call-n-1 returns true!
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
Nish - Native CPian wrote: if (call1() && call2() && call3() ....) That won;'t work. I am not supposed to call call-n unless call-n-1 returns true! :confused: Why won't that work then? With C++, you have "short-circuit" evaluation - that is, if the first item in an If statement fails, the rest won't even get evaluated. For instance, I have code like this all the time (well, when I'm not using CStrings... :-D) : if(pStr != NULL && strlen(pStr) > 0) { ... } If pStr is NULL, the first condition fails, and the second condition (strlen) won't even be evaluated. No generalization is 100% true. Not even this one.
-
Tomasz Sowinski wrote: Well, it seems that you need some kind of object wrapper over PGPError. The object could convert that to true/false or even throw some exception Shucks! It always comes down to the basics and theory. If my OOP theory was strong enough I'd not have run into this situation :-( Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
Nish - Native CPian wrote: Shucks! It always comes down to the basics and theory. If my OOP theory was strong enough I'd not have run into this situation Nish, don't get discouraged. The prime motivation for most of us to learn OOP was because of these things. Don't shy away from OOP. In a few months you will be the one telling others to wrap their functions into objects. C++ Programmers do it in class Drinking In The Sun Forgot Password?
-
Indentation is nice. In fact code that is not indented is an absolute pain to even look at. But then sometimes you get into absurd levels of indentation. Right now I am working with the PGP SDK. For certain operations I need to call about 7-10 functions sequentially. The problem is that each of these functions can be called ONLY if all the previous functions are successful. Thus I have something like this.
if(call1())
{
if(call2())
{
if(call3())
{
if(call4())
{
if((call5())
{
if(call6())
{That's just a sample, just the tip of the large iceberg. Often it get's a LOT more deeply nested than I have shown above! In such situations can we actually do away with indentation at least partially? For example would it be considered okay to do this.
if(call1())
{
if(call2())
{
if(call3())
{
if(call4())
{
if((call5())
{
if(call6())
{I have maintained a little indentation, but it's not perfectly done! Your comments are welcome
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
Excuse me Nish, I can't resist! Post it in the right forum ! :) :) Crivo Automated Credit Assessment
-
Eddie Velasquez wrote: if(!call3()) return; I can't do that. Since I need to do some cleaning up as well :( Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
do {
if (!call1())
break;
if (!call2())
break;
...
} while (false);Cleanup();
cheers, Chris Maunder
VC++ - the language that doesn't say 'no'
-
Eddie Velasquez wrote: Well, I was talking in a general sense and didn't realize you were referring to the PGP SDK in particular. My bad. PGP calls return a PGPError and you need to call IsPGPError(...) on it to figure out whether it was an error or not. Some cases you actually get an error and it's not really an error overall! Like some encryption algorithms won't work when it's an RSA key but you are supposed to ignore that since it won't cause any problem Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
Nish - Native CPian wrote: PGP calls return a PGPError and you need to call IsPGPError(...) on it to figure out whether it was an error or not. That is the worst API I've ever heard of. Jason Gerard
-
To quote Stroustrup: The Exception handling mechanism is a nonlocal control structure based on stack unwinding that can be seen as an alternative return mechanism. There are therefore legitimate uses of exceptions that have nothing to do with errors. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
I never thought of it this way but try/catch would be a good "control structure" to use instead of nested if's. Its also 100x easier to read. Is Stroustrup trying to say it should only be used as a return mechanism if it isn't used in error handling? Like it or not, I'm right.
-
Christian Graus wrote: Try/Thow/catch ( and finally in C#, dunno about C++ ) are the obvious way to deal with your situation. I don't even know how to implement exceptions :-( Might have to do some reading Actually after reading all the suggestions, I liked peterchens do{} while(0) idea :-) Nish
Regards, Nish Native CPian. Born and brought up on CP. With the CP blood in him.
// Bad example, but it shows you how to use them
for (int count=0; count<10; count++)
{
try
{
if (count%2 == 0)
throw "Even";
else
throw "Odd";
}
catch(LPSTR str)
{
MessageBox(NULL, str, "This number is:", MB_OK);
}
catch(...) // all other errors
{
MessageBox(NULL, "Unhandled exception.", "Error", MB_OK);
}
}Like it or not, I'm right.
-
To quote Stroustrup: The Exception handling mechanism is a nonlocal control structure based on stack unwinding that can be seen as an alternative return mechanism. There are therefore legitimate uses of exceptions that have nothing to do with errors. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Christian Graus wrote: There are therefore legitimate uses of exceptions that have nothing to do with errors. Well, I can't pretend to teach C++ to Bjarne! :-O But as quoted, these "legitimate uses that have nothing to do with errors" are the exception, not the rule. (pun intended!) I'm not really thinking about this too hard, but I fail to come up with a case where I would raise an exception that doesn't somehow indicate an error condition. :confused:
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation -
// Bad example, but it shows you how to use them
for (int count=0; count<10; count++)
{
try
{
if (count%2 == 0)
throw "Even";
else
throw "Odd";
}
catch(LPSTR str)
{
MessageBox(NULL, str, "This number is:", MB_OK);
}
catch(...) // all other errors
{
MessageBox(NULL, "Unhandled exception.", "Error", MB_OK);
}
}Like it or not, I'm right.
I want to add that it's a bad idea to throw exceptions for anything that doesn't indicate an "exceptional" (uncommon, erroneous) condition because in C++ exception support has a lot of overhead that's too costly for idioms that can be expressed in a cleaner and more efficient way using othe language constructs. Jason Henderson wrote: catch(...) // all other errors { MessageBox(NULL, "Unhandled exception.", "Error", MB_OK); } Just nitpicking... the message should be "unexpected exception" not "unhandled exception" because you just handled the exception!
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation -
I never thought of it this way but try/catch would be a good "control structure" to use instead of nested if's. Its also 100x easier to read. Is Stroustrup trying to say it should only be used as a return mechanism if it isn't used in error handling? Like it or not, I'm right.
Jason Henderson wrote: I never thought of it this way but try/catch would be a good "control structure" to use instead of nested if's. Its also 100x easier to read. The problem is that for most implementations, exception support has too much overhead for practical use as a "control structure" that's not directly related to exceptional (uncommon, errroneous) conditions. Check out Vishal Kochhar's excellent How a C++ compiler implements exception handling article for more information.
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation -
Eddie Velasquez wrote: I fail to come up with a case where I would raise an exception that doesn't somehow indicate an error condition Assume that you have a dozen of functions searching for some data in smart card, registry, current directory, directories listed in some env variable, etc, etc. So instead of nested constructs like this...
if (!SearchForFooInGoo(...))
{
if (!SearchForFooInBoo(...))
{
}
}... you just throw FooFoundException when one of the calls returns true. Then your exception handler does the job. Perverse, but still possible :-D Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?Yeah I thought about this but I think it's a bad idea. Check out my reasons why this use of exceptions is a bad idea post
Eddie Velasquez: A Squeezed Devil
Checkout General Guidelines for C# Class Implementation