Process is all well and good, and I know I've personally reviewed every single commit made by others on the projects I've worked on, but sometimes we inherit a steaming pile and certain smelly bits are easier to fix than others.
E.g., pre-1.5 style lack of generics - really easy to fix, unless someone's done something like made a List able to contain other Lists, ad nauseum, to implement a tree. Duplicate code - pretty easy to fix. Unused code - easy to delete. However, nullability, Swing EDT violations and swallowed exceptions all can be really hard to fix, and all could be prevented from compiling (or running) by a Java.next Haskell has no null, .NET throws an exception if you instantiate a component on the wrong thread (solving part of the EDT problem but not all of it), and no other language encourages swallowing exceptions by forcing you to write code for them before you're ready to. 2011/3/28 Cédric Beust ♔ <[email protected]> > > > On Mon, Mar 28, 2011 at 2:09 PM, Ricky Clarkson > <[email protected]>wrote: > >> The problem is that when you're coding 'the happy path' you might not want >> to think about all the error cases, but to get the happy path compiling and >> running you need to add the try..catches (yes, throws works too, but not in >> all cases - Runnable, etc.) and you're doing that before you've considered >> error-handling properly. >> >> The symptom on reasonably large codebases is that you end up with whatever >> the coder/IDE inserts for catch blocks by default, ranging from nothing >> (sometimes with // this can't happen), through logging (bonus points if each >> catch uses a different logging framework), exiting the program and >> rethrowing as runtime. >> > > That's a very good point against checked exceptions. > > I have been claiming that the strength of checked exceptions is that they > force you to think about errors very early on, but I think it's very fair to > argue that sometimes, they do so "too soon". > > What if you don't have a reporting/logging/error structure in place? What > if you know the error needs to be handled but you're not sure how just yet? > > I don't have a very good answer to that, although I suspect the right > answer lies more in the area of "process" than in software engineering > practices. > > By process, I mean things such as code reviews, or a > NotYetImplementedException, or a stub that will do the error handling at > some point in the future, or other ideas... > > -- > Cédric > > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
