3F6 Software Engineering and Design, January 2012, lecture slides 4, Brief Introduction to Programming Languages, Dr Elena Punskaya, Cambridge University Engineering Department

1. OO Programming Languages Syntax
Exceptions Handling
Elena Punskaya, op205@cam.ac.uk
1

2. OO in Java
//abstract class declaration
• Abstract class defines
public abstract class Account
{
shared implementation private int mAccountNumber;
//constructor
public Account(int accountNumber)
• Methods declared Abstract {
mAccountNumber = accountNumber;
MUST be implemented by }
// abstract method declaration
subclasses public abstract void credit(Amount amount);
}
• Interface can only define
//interface declaration
method signatures
public interface IVerifiable
{
(names, parameters,
//declaring the interface method
public boolean isVerified();
output) and no
}
implementation
//PayPal derives from Account and realises IVerifiable
public class PayPalAccount extends Account implements IVerifiable
{
• Classes can Extend other
//constructor, calls the superclass
public PayPalAccount(int accountNumber)
classes and Implement
{
super(accountNumber);
interfaces
}
//implementation of the abstract method
public void credit(Amount amount)
• By default, all class {
//send money to PayPal
methods can be overridden }
//implementation of the interface method
(extended/implemented) public boolean isVerified()
{
in the subclasses //do check and return result
}
}
© 2012 Elena Punskaya
2
Cambridge University Engineering Department
2

3. OO in C#
//abstract class declaration
• Very similar to Java
public abstract class Account
{
syntax and concepts, but private int mAccountNumber;
//constructor
also some differences public Account(int accountNumber)
{
mAccountNumber = accountNumber;
• Any non-abstract class }
// abstract method declaration
methods have to be public abstract void credit(Amount amount);
explicitly declared virtual
}
so can be overridden
//interface declaration
public interface IVerifiable
(extended/implemented)
{
//declaring the interface method
in the subclasses
}
public boolean isVerified();
• C# vs Java comparison:
//PayPal derives from Account and realises IVerifiable
public class PayPalAccount extends :Account, implements IVerifiable
{
- http://msdn.microsoft.com/en-us/ //constructor, calls the superclass
library/ms836794.aspx public PayPalAccount(int accountNumber) : base(accountNumber)
{
super(accountNumber);
}
//implementation of the abstract method
public void credit(Amount amount)
{
//send money to PayPal
}
//implementation of the interface method
public boolean isVerified()
{
//do check and return result
}
}
© 2012 Elena Punskaya
3
Cambridge University Engineering Department
3

4. OO in C++
//class declaration
• Methods need to be
class Account
{
declared virtual to be //declaring all publicly accessible methods/attributes
public:
extended (as in C#) //constructor
Account(int accountNumber)
{
• Pure virtual methods mAccountNumber = accountNumber;
}
(ending declarations with // abstract method declaration
“=0”) are equivalent to
virtual void credit(Amount amount) = 0;
abstract methods in Java
private:
int mAccountNumber;
};
• No dedicated concept of
//interface (equivalent) declaration
Interfaces, but same
class IVerifiable
{
effect is achieved by
//pure virtual (abstract) method declaration
public:
defining a class that }
virtual bool isVerified() = 0;
contains pure virtual
//PayPal derives from Account and IVerifiable
methods only
public class PayPalAccount : public Account, public IVerifiable
{
public:
• C++ and Java differences
//constructor, calls the superclass
PayPalAccount(int accountNumber):Account(accountNumber)
- http://www.cprogramming.com/ {
}
tutorial/java/syntax-differences- //declaring the implementation
java-c++.html virtual void credit(Amount amount);
//declaring the implementation
virtual bool isVerified();
}
© 2012 Elena Punskaya
4
Cambridge University Engineering Department
4

5. Error Handling
• All software encounters
error conditions during
// add error reporting to code that can fail
operations public int doSomethingRisky()
{
• Good software will <..>
if (problemNumber1Happened)
manage error situations return 1;
gracefully and robustly else if (problemNumber2Happened)
return 2;
else
• Error handling has to be return 0; //all good
implemented in the code
}
//using this method, need to build in checks
• A standard option from int result = riskyAction.doSomethingRisky();
procedural languages –
if (result == 0)
{
Error Codes //All good, can proceed
}
• Main idea:
else if(result == 1)
{
- use a code to indicate some //handle Problem1
}
specific error
else if(result == 2)
- make the function to return a {
code //handle Problem2
}
- check the return code if it is OK or
error
© 2012 Elena Punskaya
5
Cambridge University Engineering Department
5

6. Exceptions
• Errors such as the above
represent exceptions to the
// add error reporting to code that can fail
normal program flow. public void doSomethingRisky()
{
• Handling exceptions via return <..>
if (problemNumber1Happened)
codes has a number of //throw forces us to exit the current
disadvantages: //method and returns an exception object
throw problemNumber1Exception;
- Extra code needs to be inserted in each else if (problemNumber2Happened)
function to pass the errors back. throw problemNumber2Exception;
}
- If one function fails to check for errors and
pass them back, the errors will not get //using this method, wrap it in try/catch block
handled //to catch returned exceptions
try
- The extra error checking obscures the main {
function of the code, making it difficult to riskyAction.doSomethingRisky();
}
understand catch (ProblemNumber1Exception error)
- Error recovery code becomes intertwined {
with the normal operation code //handle Problem1
}
- Functions cannot use return values for catch (ProblemNumber2Exception error)
normal purposes {
//handle Problem2
• There is another way... }
• Exceptions!
© 2012 Elena Punskaya
6
Cambridge University Engineering Department
6

7. Exceptions
• C++ example //C++ class to define Exceptions
class TradingErr {
TradingErr (ErrType ee, Time tt) {e=ee; t=tt;}
• Using exceptions, the code is ErrType e; Time t;
easier to follow because the };
//main program method
error handling parts are int main() {
try {
clearly separated from the <..>
regular program flow //MyTrader() can re-throw an exception
MyTrader();
<..>
• An exception handler can //Exception handling
throw the exception again } catch (TradingError x) {
ReportError(x.e, x.t);
allowing some errors to be }
}
trapped and repaired and //------------------------------------------------
others to be propagated, e.g. void MyTrader() {
<..>
from TE_GetPrice() to //code that can re-throw an exception
MyTrader() to the main float price = TE_GetPrice(day);
<..>
method, where it is handled }
//------------------------------------------------
• Exceptions should REALLY be float TE_GetPrice(int day) {
<..>
exceptional and not be a part //code that can throw an exception
if (!Valid(day))
of normal program flow throw TradingErr(BAD_DAY,TimeNow());
<..>
}
© 2012 Elena Punskaya
7
Cambridge University Engineering Department
7

8. No Code Wars! – Tools for the Job
• Debating comparative
advantages and disadvantages
of programming languages
makes a good (if often heated)
conversation, but in reality the
choice of the language is often
dictated by the application!
• For example, in mobile
application development:
- Android, Blackberry, J2ME: Java
- iPhone: Objective-C
- Windows Phone: C#
- Symbian (RIP): C++
• Being proficient in a range of
languages helps
Source: http://www.rackspace.com/cloud/blog/2011/05/17/infographic-evolution-of-
computer-languages/
© 2012 Elena Punskaya
8
Cambridge University Engineering Department
8