see description

Software Engineering Radio podcast

Software engineers should be a primary audience for software security, but sadly we've only scratched the surface of awareness. Every once in a while, security does pop up on the software engineering radar (perhaps in a track at SD West, ROOTS, or OOPSLA). The podcast "Software Engineering Radio" released an interview that was recorded with them recently as a run up to an OOPSLA C# is basically silent on the checked exceptions issue. Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place.” Versioning with Checked Exceptions “Adding a new exception to a throws clause in a new version breaks client code. It's like adding a method to an interface. After you publish an interface, it is for all practical purposes immutable, “It is funny how people think that the important thing about exceptions is handling them. That is not the important thing about exceptions. In a well-written application there's a ratio of ten to one, in my opinion, of try finally to try catch. Or in C#, using statements, which are like try finally.

Scalability of Checked Exceptions “In the small, checked exceptions are very enticing. The trouble begins when you start building big systems where you're talking to four or five different subsystems. Each subsystem throws four to ten exceptions. Now, each time you walk up the ladder of aggregation, you have this exponential hierarchy below you of exceptions you have to deal with. You end up having to declare 40 exceptions that you might throw.… It just balloons out of control.” In his article, “Why doesn't C# have exception specifications?”, Anson Horton (Visual C# Program Manager) also lists the following reasons (see the article for details on each point): Versioning Productivity and ...