-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bell
>But how do you fully describe all of the possible errors and the difference >between warnings and fatal errors (if it is a warning you might not want to >cfthrow)? Of course, you can put any information in a hint, but it doesn't >mean that people will do it consistently or comprehensively. Warnings are really a business rule, not an exceptional condition. You could log them, ignore them - that's up to you when you're developing your business logic. I would never advocate using warnings for code flow. IMO, they promote "On Error Resume Next" style programming. If a condition is exceptional that means that it's a non-recoverable programming error and it requires that program execution stop and error handling code take over. I think a lot of people abuse the cfthrow/exception mechanism for things that really should be handled as business logic. >Have you ever been able to write an entire real world application where >none of the objects have a single pre or post condition? No matter what I >put into any of the fields, as long as it meets the data type it will be >handled appropriately? Most applications in practice don't exhibit that >level of encapsulation. Absolutely - almost every single one of them! If objects are encapsulated properly, then it's extremely easy to do. If you need configuration information, you define your component to require a configuration object during initialization. Internally in all of your methods, you need to have some form of type checking to ensure that all values passed in are valid. If those criteria are not met, then it's an exceptional condition, and you throw an appropriate error. Configuration is not a pre condition - it should be an obvious point of interface for using any given object. >How do you use strong typing to distinguish a date (passed as a string) >from a name (passed as a string)? In a strongly-typed language, you almost always have a Date data type or class. However, if for some reason, you need to design your object to take in dates as strings, you ALWAYS perform validation before your object does anything. IsValidDate. >How do you use strong typing to enforce the validation that the passed int >must be between 3 and 47, or not more than 2 bigger than another field? Of >course you can run those validations within the component, but how does the >component describe those restrictions as part of its interface? Those are business rules. If the data passed in is invalid, you raise an exception or optionally correct the data. Again, it's up to you to design the logic around that. >I personally still pass structs in certain circumstances as they can be >more performant than objects - especially when dealing with large >collections (I know I could create an object pool, but that's unnecessary >complexity in certain situations) - and because I never reuse code (just >regenerate it) I can make different design decisions than I would if the >code were a primary artifact. Then you should always be validating that the struct that is passed in conforms to the proper specification. This is a data validation issue, not a strong-typing issue in this case. >I could go on and on, but the point I am making is that just knowing the >method list and the arguments, argument data types and return type for a >class is not sufficiently descriptive for reuse (I would say it is arguably >necessary but clearly not sufficient in all cases). The rest still needs >informal commenting and informal commenting written by human beings often >leaves out special cases, exceptions, or other information you might >potentially need to know. EVERY API should have documentation. However, *reusability* from the standpoint of encapsulation and *usability* from the standpoint of an API are two different topics entirely. If you properly encapsulate objects and minimize dependencies, then reusability should be a no-brainer. I don't know of ANY API that is usable without proper documentation. :) Roland ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
