Timeline for Constructor parameter validation in C# - Best practices
Current License: CC BY-SA 2.5
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 24, 2020 at 20:54 | comment | added | mdisibio |
I think the 'IsValid' option has its place and should not be summarily dismissed. For high throughput operations on small POCO's or structs that are internal, for example. Imagine executing a ParallelFor on thousands of objects or value types each constructed from a csv line, for example. You wouldn't want to throw an exception just because one out of x million lines was missing a comma. As long as the process knows to check for 'IsValid', it can pass it along to a fallout handler.
|
|
| Jul 3, 2014 at 11:51 | comment | added | tne |
@Dunk: Even if you don't use exceptions, you should still crash explicitly, as early as possible and leaving behind as much information as possible (logs) so that debugging is as smooth as can be. After all, we're talking unexpected errors here, we can't do anything else. If the error is expected, then you handle it as best as you can, and again you do it the same way regardless of whether you use exceptions or return values. Note that I approve of return values when the error is not "exceptional" (all the .TryX methods in the framework are there for a reason) but it's completely unrelated.
|
|
| Feb 4, 2014 at 23:16 | comment | added | Dunk | What is absurd is having your application crash because some exception occurred that you weren't counting on. I'm sure your customers will appreciate the frequent program crashes that you make your users endure. In fact, I must use some of your programs. If it is important that bad data is caught then the developer can certainly use any of my methods of validation quite successfully. However, the more frequent case is developers not catching exceptions. I'd rather have my application run rather than users having to endure the pain of program crashes that the community seems to be endorsing. | |
| Jan 27, 2014 at 5:44 | comment | added | Sinaesthetic | Agreed, this is a terrible idea. Parameterized c'tors should be giving you fully built and initialized objects. If you're going to do this, you might as well abstract away the validation process and make it a client side operation, which is what you mainly see these days. Calling a constructor and then checking "did it construct?" is absurd. | |
| Aug 12, 2011 at 20:34 | comment | added | Wayne Molina |
Apart from the IsValid flag, the other two suggestions are reasonable: The first is common to set up controls that are external to the page itself, and the second is basically the Factory pattern. I disagree on the notion that Exceptions shouldn't be used, but the other advice is sound.
|
|
| Feb 25, 2011 at 2:31 | comment | added | MPelletier | Sorry, this is just too much of an anti-pattern to consider. | |
| Feb 23, 2011 at 22:26 | comment | added | CaffGeek | @Dunk, if you find exceptions hard to use, you're using them wrong. Simply put, bad input was provided to a constructor. That's an exception. The app should not continue to run unless it's fixed. Period. If it does, you end up with a worse problem, bad data. If you don't know how to handle the exception, you don't, you let it bubble up the call stack until it can be handled, even if that means simply logging, and stopping execution. Simply put, you don't need to handle exceptions, or test for them. They simply work. | |
| Feb 23, 2011 at 22:18 | comment | added | Dunk | @Chad, Yes, the class shouldn't be difficult to use. My point exactly. What if I I don't handle your exception. Ooops, very error-prone. Exceptions are not only more difficult to use but harder to read. Either method has its issues but writing code that can be easily read is far easier to do without using exceptions. That alone makes it easier to use. As for bad Initialize data, you simply return an error code. | |
| Feb 23, 2011 at 21:01 | comment | added | CaffGeek |
The POINT is that after I call a constructor, if it doesn't create because an input is invalid, that is an EXCEPTION. The app's data is now in an inconsistent/invalid state if I simply create the object and set a flag saying isValid = false. Having to test after a class is created if it's valid is horrible, very error prone design. And, you said, have a constructor, then call initialize... What if I don't call initialize? What then? And what if Initialize gets bad data, can I throw an exception now? Your class shouldn't be difficult to use.
|
|
| Feb 23, 2011 at 20:43 | comment | added | Dunk | @fuzzy: C++ has goto. So what's your point? | |
| Feb 23, 2011 at 20:42 | comment | added | Dunk | @Chad, that is your opinion, but my opinion is not wrong. It is just different from yours. I find try-catch code far more difficult to read and I've seen far more errors created when people use try-catch for trivial error handling than more traditional methods. That has been my experience and it isn't wrong. It is what it is. | |
| Feb 23, 2011 at 20:33 | comment | added | user7519 |
Java has IllegalArgumentException as part of java.lang for a reason. The Javadoc states "Thrown to indicate that a method has been passed an illegal or inappropriate argument." C# has ArgumentException for sub-classing for specific cases. C++ has throw std::invalid_argument("..."); as part of #include <stdexcept> I would say that invalid data is an exception pretty universally.
|
|
| Feb 23, 2011 at 20:27 | comment | added | CaffGeek | @Dunk, that's just wrong. | |
| Feb 23, 2011 at 19:55 | comment | added | Dunk | Nope, create a default no parameter instance. If it can't be used then so be it, because part of using the class requires you to call initialize. Sorry, I am not a fan of exceptions except for exceptional conditions. Invalid data is not an exceptional condition in my opinion. Readable and maintainable code is every bit as important as working code and code that uses too many exceptions is anything but readable. | |
| Feb 23, 2011 at 19:26 | comment | added | S.Lott | By "Create the instance" do you mean create an instance which is in an invalid state and can't be used? | |
| Feb 23, 2011 at 19:06 | history | answered | Dunk | CC BY-SA 2.5 |