Exceptions or Return codes ??!!
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel
I think no rule can applied generically. It depends upon the function context and it here that the designing part comes. Deepak Khajuria
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel
It is a sort of matter of matter of opinion, except of cause a Project managers opinion carries more weight, but, I generally take the view, If the calling code can continue to function with a straight yes/no answer then use exceptions, the caller can examine them if there is need, or rather check for particular errors. Or, If the caller can not continue without success then I want immediate access to the reason. But its not cut-n-dried. For example a serial comms class, class MyComms { //My comms can't function at all if it can't capture the port so I want the reason to be immediately available because finding out why it failed must be my next step int CaptureThePort(); //0=good,2=bad port number, 3=....... //On the other hand, when I read data I want to normally return information based on a success, the number of bytes read for example. So I would have say -1 as an error indicator and the caller would have to examine the exception codes. We do of cause have negative values available for this. Exceptions though give us the opertunity for greater detail, so I can see if it was an overrun error, parity error or a combination of errors and take action depending on the combination rather than trying to deal with the actual last error returned by the function int ReadDataFromPort(char* buffer); }; With the analogy above the a single reported error would depend upon the order of checking. int ReadDataFromPort() { if(ParityError()) return -5; if(Overrun()) return -6; ...others... } The problem here is that corruption from an overrun can damage parity, so in fact the wrong error may be returned. But if it was simply a parity error your code can make local corrections. With exception, int ReadDataFromPort() { UINT ExceptionData = 0; if(ParityError()) ExceptionData |= 1; if(Overrun()) ExceptionData |= 2; ...others... } So now of cause, your calling code can examine the problems in combination and then decide the action to take. In my humble opinion. We do it for the joy of seeing the users struggle.
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel
I guess it is personal choice. However, I find it more useful to use return codes for success or failure and the like, and use exceptions for out of the ordinary conditions, memory exceptions, etc. I think using exceptions for everything makes the code harder to read, which of course effects productivity, time and money.
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel
I think that exception are preferable for errors that are not expected or rare and error codes otherwise. Exceptions that occurs in normal situation make debugging harder if we ask ask the debugger to stop on exceptions and if we don't then we may miss some unexpected errors while debugging. In fact, if exceptions are used only for unexpected errors, then when something does not works as expected, we can start the debugger and hope that an exception will be thrown... Using exceptions also help ensure that unexpected errors are not ignored... Since we do lot of COM programming, we often return an HRESULT to indicate succes or failure at the server side... but on the client side, we will convert failed HRESULT to exceptions (and vice-versa). I think that the way Microsoft do it when importing a type library is the best of both world since we can always call the raw version of the function that returns an HRESULT if we want to but we can uses the wrapper function that will throw an exception. At work, we uses an helper class that have an operator=(HRESULT) that will convert a failure to an exception but I think that a macro would be best since it would also to do more sophisticate things (like logging the line where the error occurs in debug version or throw an exception with more information on the error). Philippe Mori
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel
Mostly my functions return an error code, usually a HRESULT. For unexpected error conditions I'll throw an exeception. Michael :-)
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel
-
Maybe this'll help:
Compile with and without exceptions: compare code size and assembly output.
My preference: Never use exceptions nor anything over which I don't have absolute control of the code generated. Sonork ID: 0.2My preference: Never use exceptions nor anything over which I don't have absolute control of the code generated. I used to be a firm believer in that. In embedded stuff certainly, in DOS days too as far as possible. UNIX/Linux, no. You use ready made Libraries, otherwise your cutting out another wheel with every bit of code you write. That same is true in Windows. For a start an ounce of mfc in your code calls up all sorts of hidden code, windows is all DLLs which your Windows code calls up. And why not? Ok, so its not open source as UNIX/Linux, but the senior MS programming team/designers are pretty good. Despite the fashion to kick MS at every opertunity, the fact is (as far as we programmers are concerned) when you do look at their code/proceedures, its bloody good. So I have no shame in using MS Dlls plus some Libs from other places. Of cause you have to take care to use reliable-traceable sources of this stuff, but otherwise its ok to borrow. We do it for the joy of seeing the users struggle.
-
My preference: Never use exceptions nor anything over which I don't have absolute control of the code generated. I used to be a firm believer in that. In embedded stuff certainly, in DOS days too as far as possible. UNIX/Linux, no. You use ready made Libraries, otherwise your cutting out another wheel with every bit of code you write. That same is true in Windows. For a start an ounce of mfc in your code calls up all sorts of hidden code, windows is all DLLs which your Windows code calls up. And why not? Ok, so its not open source as UNIX/Linux, but the senior MS programming team/designers are pretty good. Despite the fashion to kick MS at every opertunity, the fact is (as far as we programmers are concerned) when you do look at their code/proceedures, its bloody good. So I have no shame in using MS Dlls plus some Libs from other places. Of cause you have to take care to use reliable-traceable sources of this stuff, but otherwise its ok to borrow. We do it for the joy of seeing the users struggle.
Nice to see this forums does have a lot of life, and even better to see people that know their stuff. Rassman: Of course I agree with re-using other people's code .. hehe.. I'm not in the mood of re-writing a web-browser, and even less on re-writing the APIs! ;) I'm referring to my own code, and let me tell you why: I used to use STL every chance I had, then.. I looked at the dissasembly and found some pretty ugly code.. ok, I can deal with that.. but then.. if you look at the compiler's fixed bugs (buglist?) on SP2.. you'll see that hundreds of the fixes where related to the STL! omg: So, many of my bugs where caused by external code over which I had no control! all I could do was sit and wait till MS decided it was ok to launch the patch. This is, of course, unacceptable when you're running a commercial product where customers are all over you: You simply can't answer "er... the exception code was not done be me.. so you have to wait until 3rd-party releases a fix" An example: I do use exceptions in Sonork's integrated browser.. but I've made it a separate DLL so that I don't need to use exceptions in the main code.. this reduced the [main] code from 950Kb to almost 750Kb (a 21% reduction) Also, when I started porting to Linux (GCC), the GCC manual stated (at that time) that.. "exception handling is buggy" ::eek: That's the reason why I avoid (whenever possible) 3rd party code and compiler-dependency and always consider the possibility of re-inventing the wheel (based on 3rd part code) if that code is not too much/complex. But, as everyone has already stated... that is a personal choice... at the end, both ways will work, one'll give you less work, but more compiler-dependability, the other one more work, but more control. Just a matter of prios. Sonork ID: 0.2
-
Which is the way to go Exceptions or Return codes while designing functions, components?. I believe in return codes to indicate success, failure or some other status, with exceptions thrown in to indicate some error which was totally unexpected, out of way etc. But our project manager believes only in exceptions. Even status codes need to be thrown as exceptions. Absence of an exception indicates success ? What do you feel