It's UWAweek 17 (1st semester, week 8)

help3007

This forum is provided to promote discussion amongst students enrolled in CITS3007 Secure Coding. If posting a question, it's suggested you check first whether your question is answered in the unit Frequently Asked Questions (FAQ) list, and use the search box (on the right) to see if an answer to your question has already been posted.

Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.

Note that any posts must comply with the UWA Code of Conduct and the UWA Academic Conduct Policy. That means you should (a) treat everyone with respect and courtesy, and (b) not post your solutions to an assessment that's in progress.

If asking a programming question, it's recommended you read How do I ask a good question? If reporting or troubleshooting a bug in software used in the unit, it's recommend you read How to report bugs effectively.
Displaying selected article
Showing 1 of 41 articles.
Currently no other people reading this forum.


 UWA week 11 (1st semester, week 3) ↓
SVG not supported

Login to reply

👍?
helpful
2:29pm Wed 13th Mar, Arran S.

In case people are interested: although Java and Python both use exceptions, some more recent languages have moved away from exceptions as an approach to error-handling. (For instance, neither Rust nor Go have exceptions.)

A big problem with exceptions is that anytime you call a function or method, in Java, say:

String mystring = audio_recording.getArtist();

then there's often a huge range of exceptions that could be thrown, and you have very little information about what they are - so getArtist() could fail in unpredictable ways at runtime. If getArtist were part of a built-in class for your language, then the exceptions might be fairly well documented - but often the class you're using is part of some third-party library which in turn calls other libraries, any of which could throw their own exceptions.

A second problem is that exceptions often conflate two sorts of errors:

  1. Functions that can "fail" in known ways (e.g. opening a file can fail due to the file not existing)
  2. Logic errors (bugs) that occur due to mistakes by the programmer.

If (2) has occurred, then, usually, that's not something we can recover from – the code contains a bug, we've got ourselves into a bad state, and often the best thing we can do is just abort. (Or, sometimes, print a user-friendly message and then abort.)

If (1) has occurred, a way of dealing with this is to allow a method like getArtist to return, say, either a String (if it succeeded), or, say, a MalformedAudio object (if it failed), where MalformedAudio contains information about the failure. This might seem similar to exceptions – a MalformedAudio object is often a lot like how we would implement a MalformedAudioException – but the idea is that the language guarantees that those are the only two options - we can't get other sorts of exception we weren't expecting.

(For an example of an attempt to "back-port" this approach to Java, see for example the Vavr library - it includes a Java Either type, so that methods can indicate they return one type, or another.)

Cheers!

Arran

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  5:07AM Sep 06 2023
Privacy policy