-A A +A

CS2013-Strawman-SE-Software Engineering (DEPRECATED)

3 posts / 0 new
Last post
sahami
CS2013-Strawman-SE-Software Engineering (DEPRECATED)

The CS2013 Strawman Report comment period is now closed. Please see the CS2013 Ironman report for the latest CS2013 draft to comment on. Forum to comment on "SE-Software Engineering" Knowledge Area in the CS2013 Strawman report. We ask that comments related to specific text in the report please specify the page number and line number(s) of the text being commented on. Line numbers are provided on the far left-hand side of the each page.

drdbuck
drdbuck's picture
Exception Handling
field_vote: 
0
Your rating: None

Exception handling is a complex topic. The safest approach is report and terminate. However, if the exception is not due to a programming bug, most production systems will want to do some type of recovery. One type of recovery is to retry the failed operation, perhaps with an alternate implementation. This is most likely the response to an environment error. After some number of attempts, there is usually a fallback to one of the other types of handlers. The other type of handler for an exception not triggered by a programming bug is to abort the operation in progress and rollback to a previous point. This is most likely the response to a user error, and they will usually get a report about the problem.

Error handling is best covered later in the curriculum because of its complexity, and it is placed correctly in this curriculum. This is because, unlike ignoring return codes, ignoring exceptions does not lead to difficult debugging; on the contrary, deferred handling of expected exceptions arises naturally because handlers (1) potentially mask bugs; (2) add to the amount of code being debugged simultaneously; (3) often require a scope outside the method being coded, leading to conflict; and (4) compete for attention with coding the functionality, leading to neglect. Deferred handling overcomes these problems, and after debugging, error coding is the focus of a refactoring. With Java, deferred checked exception handling is not a natural outcome. Students therefor tend to practice dysfunctional error handling practices. This topic, titled "First Do No Harm: Deferred Checked Exception Handling Promotes Reliability" was accepted and will be presented by me at the JavaOne conference in San Francisco this autumn (http://oracleus.activeevents.com/connect/sessionDetail.ww?SESSION_ID=3342).

A crisis exists in the software industry because incoming employees (our students) have no clue about exception handling. Because of Java checked exceptions, they learn expedient but dysfunctional practices early on. And when they get to software engineering topics, there is not enough coverage to set them on the correct path. This curriculum has even less coverage than the previous one. This is a critical topic which needs to have some coverage at the lower level (because of Java checked exceptions) and needs several hours of coverage in software engineering level. This topic should get time from both Software Design, because error handing design is a fundamental part of design, and Software Verification Validation, because its behavior in error situations is critical to this topic.

See my manuscript: http://faculty.otterbein.edu/DBuck/HandlingExceptions.pdf

alan_fekete
SE discussion
field_vote: 
0
Your rating: None

It seems unreasonable that one could be a CS graduate without understanding something of agile development methodology; even if they don't practice it, arguments about it will surely arise in their professional life, and a CS graduate should be able to contribute. Thus I would elevate comparison of software process models (line 86) to Core-Tier1.

I also find that every graduate needs a lot of knowledge of state-of-practice IDEs; SE/Tools and Environments should cross reference SDF/Development Methods (p 142, line 146), and more clarity is needed in what is extra here beyond the SDF coverage. In my view, everyone (even non-CS graduates) need to know about version control, and I think almost all CS grads need to know about environments that automate testing, tools that help explore a large code base, and tools that help with avoiding errors. I'd add quite a bit of elective material to this topic too. Note that the core should be knowing that tools exist with various capabilities and having seen them in use; I think actually being proficient in using the tools and their features is the elective aspect.

Another topic that is missing from the SE coverage is "empirical software engineering". I'd hope that most CS graduates would know that there is lots of debate in the profession about what is good practice, and that a few issues have actually been considered by careful experiments. I'd hope that most CS graduates have seen the book "Making Software: What really Works and Why We Believe It" by Wilson and Oram, that is a great resource for this aspect of the subject.

Log in or register to post comments