Timeline for how complex a constructor should be
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 27, 2020 at 16:23 | comment | added | CharonX |
"Exceptions are meant to be exceptional. If you know some code will throw an exception, you do not wrap the code in try/catch, but you validate parameters of that code before you execute the code that can throw an exception." Good to know, I'll make sure parameters X, Y and Z are valid every time I want to construct Foo with them. Of course this means I need to be aware of all the explicit and implicit requirements for them, and spread the check code all across the code base and pray the requirements for them never change - I'm sure the code will indeed be exceptional
|
|
| Mar 8, 2018 at 0:01 | comment | added | xr280xr | @pqnet , I find that in a business application, it's almost always better to raise an error to the user, even if you don't know what happened (and log what you do know) than to just crash the application. It has been an extremely rare case, in my experience, that I couldn't jump back out to a level of the application where it is still safe to continue execution. That's not to say it doesn't happen or is even always rare, just that it can be very common to be able to continue as well despite your remark being a very common stance on this matter. | |
| Mar 7, 2018 at 23:49 | comment | added | pqnet | @xr280xr if you get an exception that you didn't expect, chances are that even if you catch it you do not know how to resume operation (because you don't know what caused the failure in the first place) and you can only bail out and raise the error to the user, or crash the program (or both) | |
| Mar 9, 2017 at 20:31 | comment | added | xr280xr | @Euphoric - Not if it's already a nullable type with only the DB preventing nulls, such as a string. A trivial point because there are a million other ways an unrelated change could unwittingly change the assumptions your lack of exception handling is dependent on. I've seen code that was perfectly safe at the time it was written now blowing up time after time. There are simple cases where the risk of not handling exceptions is acceptable, but that must be weighed carefully and is less commonly the best option. | |
| Mar 9, 2017 at 20:13 | comment | added | Euphoric | @xr280xr If you change field into nullable, you have to change type, where every invalid usage will be caught by compiler. | |
| Mar 9, 2017 at 19:24 | comment | added | xr280xr | I disagree with your exception handling philosophy. "You make sure those parameters never happen" In theory, you're right, but those params tend to find a way to happen anyway. There's either a case you didn't expect or, more likely, maintenance happens that now allows invalid values. E.G. Say a DB column your param originated from changes to nullable. The person who changed that may not know your constructor of this other class assumes it will never be null.Now your whole application may crash. Almost always better to handle exceptions that may be thrown. "Failing to plan is planning to fail" | |
| Jan 14, 2014 at 22:00 | vote | accept | Taein Kim | ||
| Jan 13, 2014 at 19:14 | comment | added | Jimmy Hoffa | It's not a requirement, it was a design decision. They could have made the constructor take a connection string and connect immediately when constructed. They decided not too because it's helpful to be able to create the object, then tweak figure out the connection string or other bits and bobbles and connect it later, | |
| Jan 13, 2014 at 19:11 | comment | added | Euphoric | @JimmyHoffa But that is specific requirement of connection class, not general rule of OOP design. I would actually call it an exceptional case, than a rule. You are basically talking about builder pattern. | |
| Jan 13, 2014 at 19:08 | history | edited | Euphoric | CC BY-SA 3.0 |
added 1050 characters in body
|
| Jan 13, 2014 at 18:59 | comment | added | Jimmy Hoffa | You may not, but many do. Think about when you create a connection object, does the constructor connect it? Is the object usable if it's not connected? In both questions the answer is no, because it's helpful to have connection objects partially-constructed so you can tweak settings and things before you open the connection. This is a common approach to this scenario. I still think constructor injection is the right approach for scenarios where object A has a resource dependency but an open method is still better than having the constructor do the dangerous work. | |
| Jan 13, 2014 at 18:57 | comment | added | Euphoric | @JimmyHoffa I see no difference between constructor method and specific method for construction. | |
| Jan 13, 2014 at 18:53 | comment | added | Jimmy Hoffa | The more appropriate solution to this is usually to add an "open" type method where construction is free, but no use can be done before you "open"/"connect"/etc which is where all the actual initialization occurs. Constructors failing can cause all sorts of issues when you in the future want to do partial-construction of objects which is a useful ability. | |
| Jan 13, 2014 at 18:51 | history | answered | Euphoric | CC BY-SA 3.0 |