Possible TRY...CATCH...END TRY

[Anders Norås [MCAD]]

That's true, but it doesn't mean that you don't need to use 'Try...Catch'

when attempting to open a file.

Yes, you need to catch exceptions when working with files, but you shouldn't
use try-catch as a lazy way to check if the files exists.

From the design guidelines for application developers (MSDN):
a.. All code paths that result in an exception should provide a method to
check for success without throwing an exception. For example, to avoid a
FileNotFoundException you can call File.Exists. This might not always be
possible, but the goal is that under normal execution no exceptions should
be thrown.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

 

[Ollie]

EXACTLY as my first post states, responsiblity, encapsualtion.....

Does this remind you of OO prinicples at all?

 

[Nay Myo Aung]

For example, you specify another server name until a connection can be
established. You'll have to declare 'i' outside the 'Try...Catch'.

When you retrieve the server names from the database, there's no need to
define i for counter.

To make a conclusion: I can only see minimal benefit in some simple cases
for a 'ReTry' statement.

Consider tens of Try...catch statments in many procedures and in many
objects. You'll feel the bigger impact.

Cheers


--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Ollie]

Totally agree, throwing or more precisely generating an exception is a time
consuming task and therefore should be avoided. we have all been told to
avoid code like this:


try
{
system.object obj = 1;
string val = (string)obj;
}
catch(System.Exception)
{
......
}

......

Ollie Riches

 

[Guest]

Yes but I would careless about how it is displayed in the IL. What I would

care more is how much the language I use to program resembles to our
everyday language. If that "syntactic sugar" than that's what I like

I like syntactic sugar too when it adds value, like the 'using' or 'lock'
statements in C#. they help you avoid problems that otherwise might happen
if you are not too careful. but I don't see retry as being useful enough,
and it certainly can be easily abused in writing badly structured program
logic.

I'm not proposing to use exceptions to control the program flow. When you
use ReTry, you basically just "retrying" what you just did in the
corresponding Try block with some variations. It is totally different
analogy from GoTo statement. So I don't thnk it is such a bad idea.

Retrying what you did with variation sounds very much to me like controlling
the program flow. for example look at the following pseudo-code

try
{
open file and do stuff
}
catch( filenotfoundexception )
{
create file
retry;
}

when it should really be written as

if( not file exist )
create file
open file and do stuff

I understand that there are certain cases where something like retry might
indeed be useful, but i think these situations are rare enough that it
doesn't justify a new keyword being introduced. especially when existing
language construct already supports it.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Hi Morten,

Yes, I know that currently this can be achieved through the use of Labels
and Goto statement. But "ReTry" statement is not currently supported
(hence
a proposal )

well, if such a keyword is introduced, it'd compile down to probably the
exact same IL as the goto variant that it supports already. it'd be
nothing
more than syntactic sugar so to speak. and I really don't see enough use
to
justify adding a whole new keyword.

not to mention generally speaking, using exceptions to control program
flow
is just a very bad idea.

From the following two code segments, which one do you think is more
elegant?

******* CODE BLOCK #1 ***********

Dim strArrayFileTryList(5) as String
strArrayFileTryList(0) = "file1.txt"
strArrayFileTryList(1) = "file2.txt"
strArrayFileTryList(2) = "file3.txt"
strArrayFileTryList(3) = "file4.txt"
strArrayFileTryList(4) = "file5.txt"

Dim intCurFileTryArray as Integer

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

If intCurFileTryArray > strArrayFileTryList.Length Then
MessageBox.Show ("Cannot open any of the files")
Else
ReTry
End If

Catch

End Try

******* END CODE BLOCK #1 ***********

******* CODE BLOCK #2 ***********

Dim strArrayFileTryList(5) as String
strArrayFileTryList(0) = "file1.txt"
strArrayFileTryList(1) = "file2.txt"
strArrayFileTryList(2) = "file3.txt"
strArrayFileTryList(3) = "file4.txt"
strArrayFileTryList(4) = "file5.txt"

Dim intCurFileTryArray as Integer

ReStart:

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

If intCurFileTryArray > strArrayFileTryList.Length Then
MessageBox.Show ("Cannot open any of the files")
Else
Goto ReStart:
End If

Catch

End Try

******* END CODE BLOCK #2 ***********

Besides, Goto statement in this example appear to be "segmented" when
reading the flow of the code. IMO, it makes more sense to "ReTry" then
ask
to "go somewhere". This is especially true when you have enormous
Try...Catch segements in one procedure because if we use GoTo statement,
we
have to label them "ReTry1", "ReTry2" or "ReTry<<TaskName>>" which I
think
distract the programmer when he/she reads the flow of the code. What do
you
think??

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/


Hi Nay Myo Aung,

You can have this functionality today

int counter = 0;
start:;
try
{
File.Open("dummy", FileMode.Open);
}
catch
{
counter++;
if(counter < 5)
goto start;
}

 

[Cor Ligthert]

How do you change the servername with your code, the sample from Herfried

I'm using OleDbDataReader object as an example for looping through the
server names table. Server names are retrieved from the database (or XML
file) (I for one never hard-code them in the array).

Who said you should hard code them? However this is not the answer on your
question accoording to your pevious sample.

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Nay,
You may want to use the Suggestion link at the VB.NET 2005 Product Feedback
Center http://lab.msdn.microsoft.com/vs2005/, however I'm not sure how high
a consideration it will get as...

VB.NET already includes it (as Mattias suggests), its been there since
VB.NET 2002. A Number of developers don't like it uses the "Goto" keyword,
however in *this* instance it is only allowed to go from the Catch Block to
the Try Block, so I don't have a big problem with it. Let me restate that in
VB.NET a label in a Try Block can only be reached from an associated Catch
block! In other words I am not referring to uses of Goto outside of a Catch
block or use of a Goto to exit a Try/Catch statement!

Here is how "ReTry" is currently implemented in VB.NET:

Try Retry:

'...something

Catch e as FileNotFoundException

'correct the error and then Goto Retry

Catch e2 as DirectoryNotFoundException

'correct the error and then Goto Retry

Catch e3 as DriveNotFoundException

'correct the error and then Goto Retry

Catch '<< catch 'unknown' error

'log the error

Finally

End Try

"ReTry" as the others have pointed out like any language construct can be
used for good as equally well as evil. I would expect any of my developers
to document very well the actual *need* for ReTry in the specific context. I
normally limit it use to prompting the user:

Try Retry:

'...something

Catch e as FileNotFoundException

If MessageBox.Show("File does not exit!",
Application.ProductName, _
MessageBoxButtons.RetryCancel, MessageBoxIcon.Question,
_
MessageBoxDefaultButton.Button2) = DialogResult.Retry
Then
GoTo retry
End If

End Try

Hope this helps
Jay

Hi All!

I think I discovered a possible improvement on .NET Framwork's
TRY...CATCH...END TRY statement. I guess most developers might also have
been discovered that at some point in their .NET development process but
continued to ignore the problem due to their workloads.

The word is RETRY.

Consider the following...

Try

'...something

Catch e as FileNotFoundException

'correct the error and then
ReTry

Catch e2 as DirectoryNotFoundException

'correct the error and then
ReTry

Catch e3 as DriveNotFoundException

'correct the error and then
ReTry

Catch '<< catch 'unknown' error

'log the error

Finally

End Try

We .NET programmers could use the keyword RETRY in the any of the Catch
block to re-execute the code in Try block. If there's another exception
thrown, we can evaulate that exception in one of the many Catch blocks
until it reached to the 'unkown' exception.

So, I propose that a new keyword ReTry should be incorporated in the .NET
Framework 2 as an improvement.

Feel free to feedback on the idea...

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Guest]

The IL part is not a valid argument that stands against adding 'ReThrow'.
With the same argument, 'If...Then' and loops are not necessary, because
they compile down to the same IL code you can write using 'GoTo'.

the point I was trying to make is that something like retry will have such
rare legitimate uses that I don't think add a new keyword justifies it,
especially when it's already supported. and in language design, if you add
new constructs for every little thing you can think of, you'd end up with a
mess on your hand.

 

[Herfried K. Wagner [MVP]]

the point I was trying to make is that something like retry will have such
rare legitimate uses that I don't think add a new keyword justifies it,
especially when it's already supported. and in language design, if you
add
new constructs for every little thing you can think of, you'd end up with
a
mess on your hand.

Full ACK. That's why I don't see a benefit in adding 'ReTry'.

 

[Herfried K. Wagner [MVP]]

Yes, you need to catch exceptions when working with files, but you
shouldn't use try-catch as a lazy way to check if the files exists.

From the design guidelines for application developers (MSDN):
a.. All code paths that result in an exception should provide a method to
check for success without throwing an exception. For example, to avoid a
FileNotFoundException you can call File.Exists. This might not always be
possible, but the goal is that under normal execution no exceptions should
be thrown.

ACK.

I prefer:

\\\

' Move this line inside the 'Try' if it can throw an exception.
If File.Exists(...) Then
Try

' Access the file.
Catch
...
Finally
...
End Try
End If
///

.... over...

\\\
If File.Exists(...) Then

' Access the file.
End If
///

.... and...

\\\
Try

' Access the file.
Catch
...
Finally
...
End Try
///

 

[Stefan Simek]

And how exactly would you implement those variations when using your
proposed ReTry statement?

Stefan

Hi Nicholas,

When I say 10 nested time, I didn't mean I would do it for the counter. 10
nested Try blocks with small variation of code that will try to do the
task differently for different exceptions.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Nay,

Actually, you can put the try/catch in a loop, counting each time you
cycle through it. When you hit the nth time, you just rethrow the
exception, instead of swallowing it.

Nesting it 10 times would be ridiculous.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Ollie,

Without ReTry, you need to duplicate the code from Try block with small
variations in nested-Try blocks. For example, using the current
Framework, you might encounter a situation where you need to write about
10 nested-Try blocks to execute for the same code (with only small
variation for each exception)...

Which is more messier?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

this is just messy IMO

Ollie

Hi,

Maybe a facility something like
Retry(2)
for retrying 2 times might help.

Of course, the call to Retry should be specific for the exception
type.

Regards,
Rakesh Rajan

:

On Fri, 3 Dec 2004 22:36:16 +1300, Nay Myo Aung wrote:

We .NET programmers could use the keyword RETRY in the any of the
Catch
block to re-execute the code in Try block. If there's another
exception
thrown, we can evaulate that exception in one of the many Catch
blocks
until
it reached to the 'unkown' exception.

So, I propose that a new keyword ReTry should be incorporated in
the
.NET
Framework 2 as an improvement.

The first thing that catched my eye when i saw your idea is that it
would
be dead easy to enter an endless loop with this. Retry again and
again
without any way to stop this. So you would need to add a counter in
each
of
your catch block to check if this block is not being executed
endlessly.
Quite messy, isn't it?

 

[David]

Hi Morten,

Yes, I know that currently this can be achieved through the use of Labels
and Goto statement. But "ReTry" statement is not currently supported (hence
a proposal )

From the following two code segments, which one do you think is more
elegant?

Neither. They're both extremely ugly. The problem is that you're using
try/catch for a ordinary loop.

******* CODE BLOCK #1 ***********

Dim strArrayFileTryList(5) as String
strArrayFileTryList(0) = "file1.txt"
strArrayFileTryList(1) = "file2.txt"
strArrayFileTryList(2) = "file3.txt"
strArrayFileTryList(3) = "file4.txt"
strArrayFileTryList(4) = "file5.txt"

Dim intCurFileTryArray as Integer

Try

SomethingToDoWithFile(strArrayFileTryList(intCurFileTryArray))

Catch e as Exception1

intCurFileTryArray += 1

If intCurFileTryArray > strArrayFileTryList.Length Then
MessageBox.Show ("Cannot open any of the files")
Else
ReTry
End If

Catch

End Try

******* END CODE BLOCK #1 ***********

All you're doing here is attempting an action on each available file,
and continuing on first success. This is a pretty common task...

For Each currentName in strArrayTryList
if SomethingToDoWithFile(filename)
return filename
End If
Next

MessageBox.Show("cannot open any file")

**********

If there must be a try/catch to handle a simple boolean operation, then
that should be encapsulated in the SomethingToDoWithFile function.
There's no need for retry here, and a Retry would make a very simple
operation much harder to read.

As somebody else mentioned, exceptions should be exceptional. They
shouldn't be used as looping constructs. And I see little use of a new
keyword that is designed to enable bad code.

 

[Herfried K. Wagner [MVP]]

When I say 10 nested time, I didn't mean I would do it for the counter. 10
nested Try blocks with small variation of code that will try to do the
task differently for different exceptions.

On the one hand you are talking about 2-liners that don't need to be added
to a separate method because of the calling overhead (which is not
necessarily the case because the JITter can do inlining of small methods),
on the other hand, you are talking about "small variations" (inside these
two lines?!). If there is little redundancy I don't see a way of
implementing that with both, a 'ReTry' statement and by placing the code in
a method. Nested 'Try...Catch' blocks are the way to go.

 

[Robby]

We VB programmers have been using On Error Goto <label> to fix errors and
rerun blocks of code for years with out trapping ourselves in endless loops.
Are you telling me that the MFC C++ programmers are not capable of doing
this.

Robby

 

[Nay Myo Aung]

However this is not the answer on your question accoording to your pevious

sample.

What do you mean?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Nay Myo Aung]

If there is little redundancy I don't see a way of implementing that with

both, a 'ReTry' statement and by placing the code in a method. Nested
'Try...Catch' blocks are the way to go.

Espeically when you are during the development phase (the time that you make
changes to the code and debug again and again), having about three or four
nested Try block to do the same thing, it just annoying to change all these
code blocks (which must have the same logic). While debugging, forgetting to
change the code on one of the Try blocks results in unexpected and
unpredictable program behaviour and makes the debugging process more time
consuming than it should.

So yea, we could put that code in a method instead. It solves the problem
for the programmers with the cost of system resources. Imagine you have to
put every 3 or 4 lines of code to a sub that is to be used in Try...Catch
blocks, I think it just a waste of sys resources, plus more code (having to
write many Sub procedure declarations and more indented Try...Block code,
just to do some simple Try...ReTry logic).

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Nay Myo Aung]

Hi Stefan,

I just copied and pasted from my other post...

'##### Retrying for same server... #####

Dim i as integer

Try
ConnectToServer(objDataReader("ServerName"))
Catch
Thread.Sleep(1000)
i += 1
if i < 10 then ReTry
Finally
If Not Connection Is Nothing Then
MessageBox.Show("Connection Timed Out")
End If
End Try

'##### END CODE #####

You could use For...Next loop for this piece of logic (and still need the
Try...Catch block in addition to that). What I have here is a logical
grouping of "performing" code, "error handling/retry" code and "clean up"
code, all in one for a task.

Furthremore, with For...Next loop, you have to write clean up code **after**
the loop exit. With my proposed method, you got a logical
grouping/integration of clean up code in the "Finally" block.

I hope it helps.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

And how exactly would you implement those variations when using your
proposed ReTry statement?

Stefan

Hi Nicholas,

When I say 10 nested time, I didn't mean I would do it for the counter.
10 nested Try blocks with small variation of code that will try to do the
task differently for different exceptions.

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Nay,

Actually, you can put the try/catch in a loop, counting each time you
cycle through it. When you hit the nth time, you just rethrow the
exception, instead of swallowing it.

Nesting it 10 times would be ridiculous.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Ollie,

Without ReTry, you need to duplicate the code from Try block with small
variations in nested-Try blocks. For example, using the current
Framework, you might encounter a situation where you need to write
about 10 nested-Try blocks to execute for the same code (with only
small variation for each exception)...

Which is more messier?

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

this is just messy IMO

Ollie

message
Hi,

Maybe a facility something like
Retry(2)
for retrying 2 times might help.

Of course, the call to Retry should be specific for the exception
type.

Regards,
Rakesh Rajan

:

On Fri, 3 Dec 2004 22:36:16 +1300, Nay Myo Aung wrote:

We .NET programmers could use the keyword RETRY in the any of the
Catch
block to re-execute the code in Try block. If there's another
exception
thrown, we can evaulate that exception in one of the many Catch
blocks
until
it reached to the 'unkown' exception.

So, I propose that a new keyword ReTry should be incorporated in
the
.NET
Framework 2 as an improvement.

The first thing that catched my eye when i saw your idea is that it
would
be dead easy to enter an endless loop with this. Retry again and
again
without any way to stop this. So you would need to add a counter in
each
of
your catch block to check if this block is not being executed
endlessly.
Quite messy, isn't it?

 

[Nay Myo Aung]

Hi Robby,

I don't know about MFC C++ programmers. But Effiel for .NET has implemented
what I'm currently proposing.

See:
http://docs.eiffel.com/eiffelstudio...guage/20_language/60_exception_mechanism.html

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Nay Myo Aung]

Hi Jay,

Thanks, I will try input my 2 cents there.

cheers
--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

Nay,
You may want to use the Suggestion link at the VB.NET 2005 Product
Feedback Center http://lab.msdn.microsoft.com/vs2005/, however I'm not
sure how high a consideration it will get as...

VB.NET already includes it (as Mattias suggests), its been there since
VB.NET 2002. A Number of developers don't like it uses the "Goto" keyword,
however in *this* instance it is only allowed to go from the Catch Block
to the Try Block, so I don't have a big problem with it. Let me restate
that in VB.NET a label in a Try Block can only be reached from an
associated Catch block! In other words I am not referring to uses of Goto
outside of a Catch block or use of a Goto to exit a Try/Catch statement!

Here is how "ReTry" is currently implemented in VB.NET:

Try Retry:

'...something

Catch e as FileNotFoundException

'correct the error and then Goto Retry

Catch e2 as DirectoryNotFoundException

'correct the error and then Goto Retry

Catch e3 as DriveNotFoundException

'correct the error and then Goto Retry

Catch '<< catch 'unknown' error

'log the error

Finally

End Try

"ReTry" as the others have pointed out like any language construct can be
used for good as equally well as evil. I would expect any of my developers
to document very well the actual *need* for ReTry in the specific context.
I normally limit it use to prompting the user:

Try Retry:

'...something

Catch e as FileNotFoundException

If MessageBox.Show("File does not exit!",
Application.ProductName, _
MessageBoxButtons.RetryCancel, MessageBoxIcon.Question,
_
MessageBoxDefaultButton.Button2) = DialogResult.Retry
Then
GoTo retry
End If

End Try

Hope this helps
Jay

Hi All!

I think I discovered a possible improvement on .NET Framwork's
TRY...CATCH...END TRY statement. I guess most developers might also have
been discovered that at some point in their .NET development process but
continued to ignore the problem due to their workloads.

The word is RETRY.

Consider the following...

Try

'...something

Catch e as FileNotFoundException

'correct the error and then
ReTry

Catch e2 as DirectoryNotFoundException

'correct the error and then
ReTry

Catch e3 as DriveNotFoundException

'correct the error and then
ReTry

Catch '<< catch 'unknown' error

'log the error

Finally

End Try

We .NET programmers could use the keyword RETRY in the any of the Catch
block to re-execute the code in Try block. If there's another exception
thrown, we can evaulate that exception in one of the many Catch blocks
until it reached to the 'unkown' exception.

So, I propose that a new keyword ReTry should be incorporated in the .NET
Framework 2 as an improvement.

Feel free to feedback on the idea...

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/

 

[Nay Myo Aung]

You showed a simple example where 'ReTry' may be useful (although I don't

see the advantages over the traditional solutions). Imagine more complex
scenarios where more complex conditions for a retry are used.

There aren't more complex "ReTry" uses, ReTry will just retry the
corresponding Try block. Nothing beyond that. And it will stop retrying
after a certain codition is met. If it is much more complex than that, we
might not use ReTry, we might use something else.

I don't think so. 'Try' is not supposed to be a loop block. There are
other, specialized language constructs for writing loops, and their usage
is preferred.

Look at this way, if we want to loop through something (such as looping
through a collection and add ListItems to a ListBox as we loop) certainly we
will use For...Next loop. But for ***ReTrying*** a task that appear in the
Try block after an exception is thrown, it doesn't make sense to use
For...Next loop but make sense to use ReTry statement. You can also put the
"final code" (such as display an error message that it cannot be retried
anymore) in the Finally block which I think totoally make sense. You cannot
utilize Finally block if you were in the For...Next loop.

So no, I don't think I'm proposing Try...ReTry as a "loop back" like
For...Next. I'm just proposing to enhance the error handling construct.

My 2 cents also...

--
Nay Myo Aung
Chief Visual Software Architect
MCP MCSD MCDBA

Email: owN0SPAMner @naymyoauN0SPAMng.name [remove NOSPAM s]
Homepage: http://hyperdisc.unitec.ac.nz/postgrad/aungn01/