Exception Handling Challenge

Background

Exception Handling Challenge

Designed by: Dan Perjar, Jeffrey Pino, Allen Clineff

Handling Exceptions Where Needed

Exception handling can easily be overlooked by beginner programmers. This is due to the linearity and small scope of the majority of programs written when one is learning java, and it is common that a student may overlook the need for handling an exception. Students may believe that they have covered all the bases, but one often finds that there are still scenarios that could potentially disrupt the operation of said program. It is imperative that students recognize common cases where checking for exceptions is encouraged, this game aims to promote the recognition of these scenarios.

Props

This game is designed to be relatively easy to set up. The administrator must choose up to 10 sets of code scenarios and the exception that should be checked from the word document provided (attached). The administrator should select 5 or fewer of these scenarios and their corresponding exception. Once chosen, each code scenario should be either written, or printed on its own note card and the exceptions to be checked for should be written on another set of note cards. At the maximum, 10 note cards are required. 10 Note cards is sufficient for rounds of 10 students each, 9 for rounds of 9 students each, and so on.

A timing device is also suggested, but not required for the game. This is to be used if the administrator chooses to include time efficiency in the scoring, in which case extra points would be given to the teams depending on how fast they completed the matching relative to the other teams.

The game requires an environment in which movement and correspondence is easily accomplished for the number of participants.

The link to the word document containing code snippets and exceptions to be checked for: [1]

Procedure

The game is based on a matching concept. The students must match the code scenario to the exception that needs to be checked for. Each code snippet and each code scenario are presented to the students on different cards.

1) The administrator is to choose even numbered teams of students of up to 10 students each. All teams must have the same number of students. The number of students determines the number of scenarios chosen. A team of 10 students requires 10 note cards, 5 with code scenarios, and 5 with their corresponding exception to be checked.

2) The object of the game is for one team to match more correct pairs than the other team(s). Points are awarded on number of matches and timing, this will be discussed further in detail later in the wiki.

3) Cards should be distributed to the students face down, one per student, until all scenarios, and all exceptions have been handed out. Students should be instructed not to look at the cards until told to do so.

4) If the administrator chooses to include timing efficiency in the game, he or she should have a timing device standing by before instructing the students to begin corresponding and matching.

5) Once ready, the administrator should give the signal for the round to begin and the students to start matching. The students must now communicate, and, in a timely fashion, match the code snippets on one persons card, to the exception that should be checked on the other set of cards. Once a match is found, the student with the exception card, should give the card to his or her team mate with the code snippet card. That person should then proceed to raise his or her hand to signal that a match has been made. Once all matches have been made and hands are up, the round is over. If timing is used, the timer should now be stopped and the time for the round recorded.

6) This procedure should be carried out for all teams, keeping track of the number of successful matches and the time of completion for all teams. The problems should not be discussed between rounds as to give each team a fair attempt. It is of benefit to each team to proceed with the matching in a manner that does not disclose the nature of the problem prematurely to the opposing team(s).

Scoring

Scoring is based on the number of successful matches, as well as timing, if the administrator chooses to implement it. It is recommended that timing be used, as tied scores are anticipated without it.

Scores should be tallied upon completion of all rounds of play.

1) Each successful match is valued at FIVE points a piece.

2) Timing determines additional points. Timing points are assigned from fastest to slowest. In the case where there are 3 competing teams, THREE bonus points for timing should be given to the fastest team, TWO to the second fastest, and ONE to the slowest. This pattern follows for any number of teams.

Scoring should begin by ranking all teams in order from fastest to slowest, and assigning the corresponding number of bonus points. Then, points for successful matches should be tallied and assigned. The winning team is the team with the greatest number of points.

Compensation for the winning team is optional.