On Monday, April 01, 2013 21:33:22 Lars T. Kyllingstad wrote: > My problem with subclasses is that they are a rather heavyweight > addition to an API. If they bring no substance (such as extra > data), I think they are best avoided.
Except that they're extremely valuable when you need to catch them. Being able to do something like try { ... } catch(FileNotFoundException fnfe) { //handling specific to missing files } catch(PermissionsDeniedException pde) { //handling specific to lack of permissions } catch(FileExceptionfe { //generic file handling error } catch(Exception e) { //generic error handling } can be very valuable. In general, I'd strongly suggest having subclasses for the various "Kind"s in addition to the kind field. That way, you have the specific exception types if you want to have separate catch blocks for different error types, and you have the kind field if you just want to catch the base exception. If anything, exceptions are exactly the place where you want to have derived classes with next to nothing in them, precisely because it's the type that the catch mechanism uses to distinguish them. - Jonathan M Davis