* Exiting from a function or procedure @ 2000-04-21 0:00 Andres Tarallo 2000-04-21 0:00 ` tmoran 2000-04-21 0:00 ` Robert A Duff 0 siblings, 2 replies; 19+ messages in thread From: Andres Tarallo @ 2000-04-21 0:00 UTC (permalink / raw) I'm currently learning ADA, my compiler is GNAT 3.12 for Windows and my sources are an old translation of a book from Henry Ledgard (Dated 1983) and the tutorials and articles I've downloaded from "The Brave ADA Programmers Site". I'm currently working in a small program to handle polinomials, in this program i have a procedure that must do something if it's parameters meet a certain condition; otherwhise it must exit. What I want to do expressed i pseudo-C lenguage is something like this: int sum(A, B){ if (A == B) /* Do something usefull with this */ else exit(0); /* something went wrong */ endif; } From my readings i learned that i have to do this via exceptions; the way to do this I achieved is: function "+"(izq, der: in term) return term is aux: term; error_suma: exception; begin if (izq.exponente = der.exponente) then aux.coeficiente:= (izq.coeficiente + der.coeficiente); aux.exponente:= izq.exponente; return aux; else raise error_suma; end if; exception when error_suma => Put(" ERROR !!!"); end; When I compile this it compiles fine, however i get a warning telling me that this could raise an exception during runtime. I'm still not very familiar with exceptions and it's handling, Am I doing things in the right way? After displaying the message may program will terminate? Thanks in advance, apologize me for my grammar and vocabulary; english is not my mother tongue Andres Tarallo (atarallo@chasque.apc.org) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Exiting from a function or procedure 2000-04-21 0:00 Exiting from a function or procedure Andres Tarallo @ 2000-04-21 0:00 ` tmoran 2000-04-21 0:00 ` Andres Tarallo 2000-04-22 0:00 ` Robert Dewar 2000-04-21 0:00 ` Robert A Duff 1 sibling, 2 replies; 19+ messages in thread From: tmoran @ 2000-04-21 0:00 UTC (permalink / raw) >this program i have a procedure that must do something if it's parameters >meet a certain condition; otherwhise it must exit. Do you mean the procedure must exit in the sense of return, or exit in the sense of stopping the program? Your C examples suggests the latter. You could use "pragma import" on the C "exit" procedure and just call it, exactly as your C program does. Your code using an exception is fine except that it catches the exception, prints the error message, and then tries to drop out the bottom of the function without returning any value. You probably want to add a "raise;" statement after the Put, to re-raise the exception. Note also that some compilers are only half-smart and will give a warning on the construct if ... then ... return some_value; else ... raise some_exception; end if; end some_function; because the compiler realizes that if the program takes the "else" branch it will drop out the bottom of the function without returning any value, but the compiler doesn't realize that some_exception will be raised and prevent reaching the bottom of the function. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-21 0:00 ` tmoran @ 2000-04-21 0:00 ` Andres Tarallo 2000-04-22 0:00 ` Robert Dewar 2000-04-22 0:00 ` Robert Dewar 1 sibling, 1 reply; 19+ messages in thread From: Andres Tarallo @ 2000-04-21 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1522 bytes --] tmoran@bix.com escribi� en mensaje ... >>this program i have a procedure that must do something if it's parameters >>meet a certain condition; otherwhise it must exit. > Do you mean the procedure must exit in the sense of return, or exit >in the sense of stopping the program? Your C examples suggests the >latter. Thats the idea !!! when something goes wrong display a message and stop. > You could use "pragma import" on the C "exit" procedure and just >call it, exactly as your C program does. Your code using an exception >is fine except that it catches the exception, prints the error message, >and then tries to drop out the bottom of the function without returning >any value. You probably want to add a "raise;" statement after >the Put, to re-raise the exception. Ok, thanks for the advice, remember that this are my first programas in ADA and still i'm not very familiar with the languaje. > Note also that some compilers are only half-smart and will give a >warning on the construct >[..] >because the compiler realizes that if the program takes the "else" >branch it will drop out the bottom of the function without returning >any value, but the compiler doesn't realize that some_exception will >be raised and prevent reaching the bottom of the function. It does give me a warning, but some thing do happen to some C/C++ compilers so i didn't bothered in that message Thanks Andres Tarallo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-21 0:00 ` Andres Tarallo @ 2000-04-22 0:00 ` Robert Dewar 2000-04-22 0:00 ` tmoran ` (3 more replies) 0 siblings, 4 replies; 19+ messages in thread From: Robert Dewar @ 2000-04-22 0:00 UTC (permalink / raw) Well first of all let's start with your last statement: > It does give me a warning, but some thing do happen to > some C/C++ compilers so i didn't bothered in that message Big mistake! Never ignore warnings from GNAT. They almost always point to something that is wrong, and if you don't understand them, you should get someone to help you. Here is a cleaned up version of your function: function "+" (Izq, Der: in Term) return Term is Aux : Term; Error_Suma : exception; begin if (Izq.Exponente = Der.Exponente) then Aux.Coeficiente := Izq.Coeficiente + Der.Coeficiente; Aux.Exponente := Izq.Exponente; return Aux; else raise Error_Suma; end if; exception when error_suma => Put(" ERROR !!!"); end "+"; Now when you compile that, you get: 20. Put(" ERROR !!!"); | >>> warning: "return" statement missing following this statement >>> warning: Program_Error may be raised at run time and indeed this warning is 100% accurate, and points to the serious bug in your function. if the line ERROR is printed, then indeed Program_Error will be raised, and it is pretty likely (I would guess 100% if you are a beginner) that this was NOT intentional. So NEVER EVER ignore warnings, consider them as errors. In fact you might want to use -gnatwe so the compiler will treat them as errors enforcing this discipline. The particular problem is that a function MUST terminate with a return statement for ALL possible excecution paths, and clearly your function disobeys this rule for the case where an exception is raised. We will address the fix below. But before we do, several style comments on your program, illustrated by the clean up above. a) indent properly, using standard style, you indented a bit but in an inconsistent manner and indentation is one thing that is pretty uniform in Ada, because the RM indicates a strong recommendation for indentation. b) use upper/lower case for identifiers as I have done above, this is not required, but again is very much the most common Ada standard. There are other acceptable capitalization styles used sometimes in Ada, but all lower case is NOT one of them. So get rid of that unwelcome C habit! c) Use a bit more white space to let the code breathe. This is personal taste, but again is pretty standard Ada style. d) Repeat the name of the function on the end line e) don't put unnecessary parentheses around expressions. In particular avoid doing this for conditionals, that's another C habit that need not be imported into Ada. Those comments are style comments reflected in the cleaned up code above. Now for some more extensive programming comments. a) use comments. Students often get into the appalling habit of writing code first and commenting it later. That is terrible for three reasons: 1. You don't get into the life long habit of always writing comments and if you don't get into that habit your code will NEVER be well documented. 2. Going back and adding documentation later works for trivial programs but does not scale up, you simply cannot do this on large programs 3. If you have no comments in the code as you write it, it makes it much harder for people to help (if you were one of my students I would refuse to help at all, because I would have told you in advance that you had better not ever show me uncommented code, since I won't help, but I will note it down and take off points for the assignment, and my TA's are instructed the same way :-) b) use decent names for things, not abbreviations. I cannot even guess what Izq means. One might guess that Der is deriviative, but if so, then spell it out. It's a bit more work to write, but in Ada, the cardinal rule is to write code that can be easily read. A decent editor that does name completion can help if you are a slow typist :-) c) Perhaps this is jumping a bit far from what you know, but likely the better code for the two assignments is Aux := (Coefiente => Izq.Coeficiente + Der.Coeficiente, Exponente => Izq.Exponente); You can probably guess how this works just by looking at the example. Technically it is a record aggregate, and you should be able to find the detailed description in your Ada book. It has the advantage of insisting that you remember to set all fields. That does not really matter when there are only two of them, but it can be a real advantage if there are many. You can go a step further, just eliminate Aux completely from your program, and write: return (Coefiente => Izq.Coeficiente + Der.Coeficiente, Exponente => Izq.Exponente); OK, now finally back to the original issue. You have an error situation in this function, and the proper thing to do is to raise an exception, but it is wrong to define this exception INSIDE the function, why? because the idea of an exception is to let the CALLER decide what to do, and for that the caller must be able to see the exception. How to deal with this, well the function "+" must appear inside a package, and that means the specification appears in the package spec. Here is an idea of how that should be done: function "+" (Izq, Der: in Term) return Term; -- This function takes two .... and ..... and returns a -- Term which .... The exponents of Izq and Der must be -- equal -- -- Error conditions: raises Error_Suma if the exponents -- are unequal. I can't fill in the .... since I don't know what this does :-). Just to remind you, the body now looks like: function "+" (Izq, Der: in Term) return Term is begin if Izq.Exponente = Der.Exponente then return (Coefiente => Izq.Coeficiente + Der.Coeficiente, Exponente => Izq.Exponente); else raise Error_Suma; end if; end "+"; Now, it is up to the caller to decide what to do about this error. For a simple program it may well be enough to do nothing at all. Now what happens if the error occurs, well you have an unhandled exception and so the program terminates with a nice message saying that the exception Error_Suma was unhandled, and then you can if necessary go into the debugger and find out why that happened. Note how much nicer that is than the C style of returning an error code which if you forget to check it, means that the error is blithely ignored. This has caused bugs in many many C programs. For example early versions of the Unix editor just ignored a disk full condition, so you lost your edited file with no warning that this had happened. Or perhaps the CALLER will have an exception handler to detect the error and take appropriate action. One further point. In some real large programs, there is a protocol of logging errors, and that may mean it is appropriate to modify your function as follows: function "+" (Izq, Der: in Term) return Term is begin if Izq.Exponente = Der.Exponente then return (Coefiente => Izq.Coeficiente + Der.Coeficiente, Exponente => Izq.Exponente); else raise Error_Suma; end if; exception when Error_Suma => Error_Log ("error occured in "+" with args ...."); raise; end "+"; Here the raise with no argument (often called a reraise), reraises the same exception, so that the caller can deal with it as appropriate. Finally a quick note about the advice you received to interface the C function exit. This was non-Ada advice, and shows the risk of getting advice from CLA, you can often get correct advice which answers the wrong problem. Interfacing exit answered the question of "how can I exactly duplicate the style and content of my C program in Ada?" But that's not what we are interested in doing here since you are learning Ada :-) Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` Robert Dewar @ 2000-04-22 0:00 ` tmoran 2000-04-22 0:00 ` Ray Blaak 2000-04-23 0:00 ` Robert Dewar 2000-04-22 0:00 ` Ken Garlington ` (2 subsequent siblings) 3 siblings, 2 replies; 19+ messages in thread From: tmoran @ 2000-04-22 0:00 UTC (permalink / raw) > So NEVER EVER ignore warnings, consider them as errors. In > fact you might want to use -gnatwe so the compiler will > treat them as errors enforcing this discipline. This is not always a good idea. For instance if OK then return some_value; else Log_And_Raise_Error; end if; end some_function; is a perfectly legitimate paradigm in Ada that would become illegal in Gnat with -gnatwe, since the compiler doesn't know that Log_And_Raise_Error will never return. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` tmoran @ 2000-04-22 0:00 ` Ray Blaak 2000-04-22 0:00 ` David Starner 2000-04-23 0:00 ` Robert Dewar 1 sibling, 1 reply; 19+ messages in thread From: Ray Blaak @ 2000-04-22 0:00 UTC (permalink / raw) tmoran@bix.com writes: > > So NEVER EVER ignore warnings, consider them as errors. In > > fact you might want to use -gnatwe so the compiler will > > treat them as errors enforcing this discipline. > > This is not always a good idea. For instance > if OK then > return some_value; > else > Log_And_Raise_Error; > end if; > end some_function; > is a perfectly legitimate paradigm in Ada that would become > illegal in Gnat with -gnatwe, since the compiler doesn't know > that Log_And_Raise_Error will never return. I always put in a dummy return in these cases, just to avoid such warnings, and for safety if the log routine ever *doesn't* raise an exception (e.g. maybe due to some maintenance change in the future). Of course, I also prefer a single return point, so I would have written: result := default_value; if OK then result := ok_value; else Log_And_Raise_Error; end if; return result; end some_function; -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` Ray Blaak @ 2000-04-22 0:00 ` David Starner 0 siblings, 0 replies; 19+ messages in thread From: David Starner @ 2000-04-22 0:00 UTC (permalink / raw) On 22 Apr 2000 12:33:32 -0700, Ray Blaak <blaak@infomatch.com> wrote: >tmoran@bix.com writes: >> > So NEVER EVER ignore warnings, consider them as errors. In >> > fact you might want to use -gnatwe so the compiler will >> > treat them as errors enforcing this discipline. >> >> This is not always a good idea. For instance >> if OK then >> return some_value; >> else >> Log_And_Raise_Error; >> end if; >> end some_function; >> is a perfectly legitimate paradigm in Ada that would become >> illegal in Gnat with -gnatwe, since the compiler doesn't know >> that Log_And_Raise_Error will never return. > >I always put in a dummy return in these cases, just to avoid such warnings, and >for safety if the log routine ever *doesn't* raise an exception (e.g. maybe due >to some maintenance change in the future). Of course, that masks a bug. Log_And_Raise_Error is defined to raise an exception - if it doesn't then it's buggy. Either that, or the maintenance programmer should have fixed every use of Log_And_Raise_Error - and a dummy return is unlikely to be the correct fix. At least in developement, raising Program_Error is a good result. -- David Starner - dstarner98@aasaa.ofe.org Finger dvdeug@x8b4e53cd.dhcp.okstate.edu for more information. Only a nerd would worry about wrong parentheses with square brackets. But that's what mathematicians are. -- Dr. Burchard, math professor at OSU ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` tmoran 2000-04-22 0:00 ` Ray Blaak @ 2000-04-23 0:00 ` Robert Dewar 2000-04-23 0:00 ` tmoran 1 sibling, 1 reply; 19+ messages in thread From: Robert Dewar @ 2000-04-23 0:00 UTC (permalink / raw) In article <BKmM4.214$nb6.208368@news.pacbell.net>, tmoran@bix.com wrote: > > So NEVER EVER ignore warnings, consider them as errors. In > > fact you might want to use -gnatwe so the compiler will > > treat them as errors enforcing this discipline. > > This is not always a good idea. For instance > if OK then > return some_value; > else > Log_And_Raise_Error; > end if; > end some_function; > is a perfectly legitimate paradigm in Ada that would become > illegal in Gnat with -gnatwe, since the compiler doesn't know > that Log_And_Raise_Error will never return. Two responses: I still prefer to work with -gnatwe, and then use pragma Warnings (Off) to locally suppress a warning that can be ignored, always adding a comment as to why this is being done. Second, in this particular case, that is exactly why we added the pragma No_Return to GNAT. When using GNAT, if you have a procedure like Log_And_Raise_Error, then you declare that procedure with pragma No_Return, and two things happen, first the compiler checks that there are no return statements in Log_And_Raise_Error, second the warning is suppressed at the point of call. The trouble with leaving warnings in your code is that you can easily get into the habit of ignoring warnings, and we see many people generating lots of extra work for themselves this way. GNAT goes to a considerable effort to generate all kinds of useful warnings -- we often get the reaction when people port to GNAT from another compiler that they discover latent bugs in their code from these warnings. So getting into the habit of never ignoring warnings and insisting on warning-free code is a good one, and I repeat my advice to follow this approach. Using -gnatwe (as we do when we compile GNAT) is a good way to enforce this discipline. Of course the pragmas Warnings (Off) and No_Return are GNAT specific, but there are several points to be made there: 1. Unrecognized pragmas are ignored, it is VERY unlikely that any other compiler recognizes these pragmas unless it implements them. 2. Warnings are pretty compiler dependent anyway, GNAT tends to be pretty aggressive in looking for opportunities to generate warnings. Note that some compilers don't even generate warnings at all for missing blocked return paths in functions. 3. In several cases, pragmas initially introduced into GNAT are being considered for more general adoption (pragma Unsuppress is an example). Perhaps pragma Warnings (Off) and No_Return are other candidates. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-23 0:00 ` Robert Dewar @ 2000-04-23 0:00 ` tmoran 2000-04-24 0:00 ` Robert Dewar 2000-04-24 0:00 ` Robert Dewar 0 siblings, 2 replies; 19+ messages in thread From: tmoran @ 2000-04-23 0:00 UTC (permalink / raw) >The trouble with leaving warnings in your code is that you can >easily get into the habit of ignoring warnings, and we see many Agreed. >Of course the pragmas Warnings (Off) and No_Return are GNAT >specific, but there are several points to be made there: In this case, I could dispense with the Gnat warning by using pragma Warnings(Off) or No_Return, but instead I'd just get new warnings, about unrecognized pragmas, from other compilers. So in either case warnings will be raised, at least until all (or at least most) Ada compilers implement one or both of those pragmas. In this specific case, rewriting usually removes the warning, though it may confuse the maintenance programmer who worries "what value is returned when things are not OK?". It's also subject to the previously noted problem "what happens if there's a bug and Log_And_Raise_Error actually *does* return?" if not OK then Log_And_Raise_Error; end if; return some_value; end some_function; > GNAT tends to be pretty aggressive in looking for opportunities to > generate warnings. Note that some compilers don't even ... A classic tradeoff in this case between Type 1 and Type 2 error probabilities. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-23 0:00 ` tmoran @ 2000-04-24 0:00 ` Robert Dewar 2000-04-24 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 2000-04-24 0:00 UTC (permalink / raw) In article <vzJM4.1253$t25.356170@news.pacbell.net>, tmoran@bix.com wrote: > if not OK then > Log_And_Raise_Error; > end if; > return some_value; > end some_function; I find the above code a very poor choice, precisely because, as Tom notes, it will worry a maintenance programmer as to what is going on! Far better is if not OK then Log_And_Raise_Error; raise Program_Error; end if; or if you want to take the effort if not OK then Log_And_Raise_Error; raise Impossible_Exception_Cannot_Be_Raised; Still for those using GNAT, use the opportunity to learn about pragma No_Return, since it is a very clear way of documenting the special case of a procedure that never returns. By the way, I think it is a terrible design choice in Ada 95 that Raise_Exception can return to the caller. We end up special casing this in GNAT to avoid the warning in this case (raising Program_Error seems reasonable enough if Raise_Exception returns and the return path is unblocked. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-23 0:00 ` tmoran 2000-04-24 0:00 ` Robert Dewar @ 2000-04-24 0:00 ` Robert Dewar 2000-04-24 0:00 ` tmoran 1 sibling, 1 reply; 19+ messages in thread From: Robert Dewar @ 2000-04-24 0:00 UTC (permalink / raw) In article <vzJM4.1253$t25.356170@news.pacbell.net>, tmoran@bix.com wrote: > A classic tradeoff in this case between Type 1 and Type 2 > error probabilities. Actually I see no trade off here, there is no advantage in a compiler NOT warning in cases which clearly warrant a warning. We find surprisingly few cases of warnings that are not warranted, and they are easily dealt with. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-24 0:00 ` Robert Dewar @ 2000-04-24 0:00 ` tmoran 2000-04-24 0:00 ` Robert Dewar 0 siblings, 1 reply; 19+ messages in thread From: tmoran @ 2000-04-24 0:00 UTC (permalink / raw) > > A classic tradeoff in this case between Type 1 and Type 2 > > error probabilities. > > Actually I see no trade off here, there is no advantage in a > compiler NOT warning in cases which clearly warrant a warning. If a situation "clearly" warrants a warning, then it warrants a warning. But there are cases where the "clearly warrants" is disputable. One reason for deciding not to have the compiler issue a particular warning might be: >The trouble with leaving warnings in your code is that you can >easily get into the habit of ignoring warnings, and we see many ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-24 0:00 ` tmoran @ 2000-04-24 0:00 ` Robert Dewar 0 siblings, 0 replies; 19+ messages in thread From: Robert Dewar @ 2000-04-24 0:00 UTC (permalink / raw) In article <ITRM4.955$7N2.399746@news.pacbell.net>, tmoran@bix.com wrote: > If a situation "clearly" warrants a warning, then it warrants > a warning. But there are cases where the "clearly warrants" > is disputable. General claims like this are a bit unconvincing, an example would be helpful. As I said earlier, I do not know of any warnings in GNAT where there is a good argument for omitting the warning (or they would not be there). On the other hand, we get quite a bit of input from users asking for additional warnings. > One reason for deciding not to have the > compiler issue a particular warning might be: > > >The trouble with leaving warnings in your code is that you > >can easily get into the habit of ignoring warnings, and we > > see many Actually, our experience is most often that people ignore warnings which ARE useful, and very often we get examples of code that is full of warnings, ALL of which represent real problems, and the programmer has just ignored them all on the grounds that warnings are usually useless. My point here is that, again in our experience, the warnings in GNAT are definitely useful and should NOT be ignored. I am definitely not making a point about warnings in general. I am quite aware that some compilers generate a lot of useless warnings! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` Robert Dewar 2000-04-22 0:00 ` tmoran @ 2000-04-22 0:00 ` Ken Garlington 2000-04-22 0:00 ` Pablo Moisset 2000-04-24 0:00 ` Scott Ingram 3 siblings, 0 replies; 19+ messages in thread From: Ken Garlington @ 2000-04-22 0:00 UTC (permalink / raw) Everything Dr. Dewar said, plus this: * Ledgard's book was pretty minimal with respect to explaining Ada83, and of course it doesn't address all of the capabilities now available in the current version of Ada (and supported by GNAT). When you get past the basics, try to find some time to explore the "bigger picture" with a more recent reference. * You've defined what should happen if your exponents are unequal. Have you considered what (if anything) should happen if the sum of the coefficients will be too big to fit in the range of the result? See the description of CONSTRAINT_ERROR in sections 10.1 and 10.3 of Ledgard. Also, one other note: For GNAT, the statement "the program terminates with a nice message saying that the exception... was unhandled" is probably true. However, I don't think the standard requires "a nice message." If you want your program to behave nicely (and consistently) when compiled with any compiler, you will need to define that behavior within the program. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` Robert Dewar 2000-04-22 0:00 ` tmoran 2000-04-22 0:00 ` Ken Garlington @ 2000-04-22 0:00 ` Pablo Moisset 2000-04-23 0:00 ` Robert Dewar 2000-04-24 0:00 ` Scott Ingram 3 siblings, 1 reply; 19+ messages in thread From: Pablo Moisset @ 2000-04-22 0:00 UTC (permalink / raw) Hi > b) use decent names for things, not abbreviations. I cannot > even guess what Izq means. One might guess that Der is > deriviative, but if so, then spell it out. It's a bit more > work to write, but in Ada, the cardinal rule is to write > code that can be easily read. A decent editor that does > name completion can help if you are a slow typist :-) It was easy for me to interpret Izq and Der. They mean 'izquierdo' and 'derecho' (left and right in spanish). :) Nevertheless I think the rules you stated are right. Pablo ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` Pablo Moisset @ 2000-04-23 0:00 ` Robert Dewar 0 siblings, 0 replies; 19+ messages in thread From: Robert Dewar @ 2000-04-23 0:00 UTC (permalink / raw) In article <39024681.D36A4477@usc.edu>, Pablo Moisset <pmoisset@usc.edu> wrote: > It was easy for me to interpret Izq and Der. They mean > 'izquierdo' and 'derecho' (left and right in spanish). :) > Nevertheless I think the rules you stated are right. OK, well probably they should be spelled out, unless these abbreviations are *so* universally understood that they cause no problems. For instance I do not mind Lo and Hi as abbreviations for Low and High, since they are not going to cause any confusion. Note that even in the RM, some abbreviations are considered acceptable, e.g. IO for Input_Output, since it would really be a bit of a nuisance to have to write: with Text_Input_Output; use Text_Input_Output; all the time, and if anything IO is *more* familiar than the full phrase. So the rule against language abbreviations is not absolute, and if I had been more fluent in Spanish (I recognize the full words, but did not click to the abbreviations :-), it might well be that these are in the Lo,Hi category. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-22 0:00 ` Robert Dewar ` (2 preceding siblings ...) 2000-04-22 0:00 ` Pablo Moisset @ 2000-04-24 0:00 ` Scott Ingram 3 siblings, 0 replies; 19+ messages in thread From: Scott Ingram @ 2000-04-24 0:00 UTC (permalink / raw) Robert Dewar wrote: > b) use decent names for things, not abbreviations. I cannot > even guess what Izq means. One might guess that Der is > deriviative, but if so, then spell it out. It's a bit more > work to write, but in Ada, the cardinal rule is to write > code that can be easily read. A decent editor that does > name completion can help if you are a slow typist :-) > Izq, short for Izquierda (Left,) and Der, short for Derecho (Right.) While these abbreviations are fairly common in Spanish and Portuguese, they do make it extremely difficult for others to read the code. -- Scott Ingram Sonar Processing and Analysis Laboratory Johns Hopkins University Applied Physics Laboratory ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-21 0:00 ` tmoran 2000-04-21 0:00 ` Andres Tarallo @ 2000-04-22 0:00 ` Robert Dewar 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 2000-04-22 0:00 UTC (permalink / raw) In article <rm0M4.39$t25.17152@news.pacbell.net>, tmoran@bix.com wrote: > Note also that some compilers are only half-smart and will > give a warning on the construct > if ... then ... return some_value; > else ... raise some_exception; > end if; > end some_function; > because the compiler realizes that if the program takes the > "else branch it will drop out the bottom of the function > without returning any value, but the compiler doesn't realize > that some_exception will be raised and prevent reaching the > bottom of the function. Hard to believe that a compiler would have a bug in it that was this transparent ... however, the original program should certainly generate a warning for the exception handler itself since that will indeed raise Program_Error if executed as a result of terminating the function without returning a value. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Exiting from a function or procedure 2000-04-21 0:00 Exiting from a function or procedure Andres Tarallo 2000-04-21 0:00 ` tmoran @ 2000-04-21 0:00 ` Robert A Duff 1 sibling, 0 replies; 19+ messages in thread From: Robert A Duff @ 2000-04-21 0:00 UTC (permalink / raw) "Andres Tarallo" <atarallo@chasque.apc.org.NOSPAM> writes: > function "+"(izq, der: in term) return term is > aux: term; > error_suma: exception; > begin > if (izq.exponente = der.exponente) then > aux.coeficiente:= (izq.coeficiente + der.coeficiente); > aux.exponente:= izq.exponente; > return aux; > else > raise error_suma; > end if; > exception > when error_suma => Put(" ERROR !!!"); > end; Just raise the exception, and don't handle it. That is, get rid of "exception when ... ;". Then the program will stop on that error. > When I compile this it compiles fine, however i get a warning > telling me that this could raise an exception during runtime. That's probably a different problem. I can't tell from the excerpt you gave. > I'm still not very familiar with exceptions and it's handling, > Am I doing things in the right way? After displaying the message may program > will terminate? No. After you handle an exception, the program continues on, unless you re-raise the exception. If you want the exception to kill the program, then just raise it. Don't handle it. - Bob ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2000-04-24 0:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-04-21 0:00 Exiting from a function or procedure Andres Tarallo 2000-04-21 0:00 ` tmoran 2000-04-21 0:00 ` Andres Tarallo 2000-04-22 0:00 ` Robert Dewar 2000-04-22 0:00 ` tmoran 2000-04-22 0:00 ` Ray Blaak 2000-04-22 0:00 ` David Starner 2000-04-23 0:00 ` Robert Dewar 2000-04-23 0:00 ` tmoran 2000-04-24 0:00 ` Robert Dewar 2000-04-24 0:00 ` Robert Dewar 2000-04-24 0:00 ` tmoran 2000-04-24 0:00 ` Robert Dewar 2000-04-22 0:00 ` Ken Garlington 2000-04-22 0:00 ` Pablo Moisset 2000-04-23 0:00 ` Robert Dewar 2000-04-24 0:00 ` Scott Ingram 2000-04-22 0:00 ` Robert Dewar 2000-04-21 0:00 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox