New answers tagged

0

Your library seems to be something like a utilities collection, with elements that might come in handy for some of your users' tasks. When including an exception class in such a library, I can see two different motivations: The exception class is used in other parts of the library (and then it's mandatory to either include the class or declare a dependency ...


1

I have a very basic library that serves the purpose of collecting some useful but simple pieces of code. Like for example a Percent struct or functions like ToDegrees() and ToRadians(), just to give an idea. This sounds very much like it's a toolbox, and there's no inherent requirement of a toolbox using its own tools. That's the short answer. More ...


-1

The purpose of exceptions is to be able to propagate errors far from where they happen, so handling them later. This could be useful for example in a library, where you will want the calling program to define what to do with every error. But among the library itself, most of the time it doesn't matter. You will want to handle errors as soon as possible, in a ...


4

There is nothing wrong in placing custom exception classes in a library for the sole purpose of reusage (whereelse should they be placed if they are required by more than one assembly)?. What I think is debatable is placing other things in that library as well, things which have nothing to do with those exceptions. So why not place the exceptions in a ...


0

As with most things in programming, the answer is "it depends". At one level, your C code absolutely depends on code in the standard library - you aren't going to re-implement printf, for example. But on a higher level, things get murkier. Using third-party solutions can make life a lot easier for some tasks, but adding a third-party dependency ...


0

Your question/situation is a good example of using the DRY - Don't Repeat Yourself principle. DRY - Don't repeat yourself: The name pretty much says it all. Don't repeat yourself (just did it again! :) The main idea behind this principle is to ensure that changes are confined to one location/scope and there is no duplicate code lying around. The motivation ...


3

Generalizing the question, should new code depend on existing code? All new code depends on existing code. If your new code adds 1 and 2 together it depends on existing add code. Even if it’s assembly you end up depending on micro code. The big difference is when you depend on unstable code. Your code is only as stable as the code it depends on. If ...


1

According to Uncle Bob and others: A function should do one thing only and do it well Accordingly, if printError() only prints error and prints errors well, there is no benefit in reinventing the wheel and reimplement the same again in another context. Moreover, if doSomething() would by itself do something and print errors, it would no longer do one thing....


Top 50 recent answers are included