Tag Info

New answers tagged

3

Is putting stack trace in files is bad? Since writing to files has nothing to do with UX, is just that security issue that makes it look bad idea? No it is not a bad thing. It is a good thing. Fatal errors need consistent and clear logs and information to attempt to reproduce the error, verify the error seen, triage, resolution and then testing. ...


1

I think that the requirement not to change the behavior of the legacy application is pretty restrictive. Further, I completely agree with you that the right thing to do is just throw the Exception and catch it where it needs to be caught, by the UI. That said, given the requirement not to change the behavior, I think your solution is a tolerable compromise, ...


1

How about a different change to the methods: Gut all the existing methods, move the code into new methods. The existing methods contain only the exception-swallower and otherwise call the new methods to do the work. This leaves the legacy form that you can call if you want it swallowed or the new form if you want it to throw when it should throw. This ...


0

I think your best bet is to simply use the catch block to log the exception and any other information that will help you trace the error, including a stack trace. This satisfies your callers, who don't have to change their method signatures, and further satisfies the developers, who now have a way to diagnose problems involving thrown exceptions.


1

Whatever you do, document it. If users do not like the default behaviour you provide, they can then adapt your function to their needs. Here are a couple of possibilities, sorted from best to least preferred (in my opinion). There is no sensible value in these cases, so we need to return the absence of a value. This might be a double* or double? with a ...


1

A class is responsible for its own state. So validate to the extent that it keeps or puts things in an acceptable state. If a module will be used in a wrong way, we want to throw exception immediately instead of any unpredictable behavior. No, don't throw an exception, instead deliver predictable behavior. Corollary to state responsibility is to make ...


1

There are major differences between throwing exceptions and returning error objects, in particular, exceptions create many new code-flow paths which are not explicitly visible in the source code, callers have no idea what kinds of errors they can expect, they propagate automatically, and they make the code much less verbose and easier to read and write. ...


1

Well, it could conceivably be useful. If the function shouldn't have used exceptions anyway. But your type is all wrong: You have to allocate the exception dynamically (or at least allow for it being allocated dynamically) to allow for returning a sub-type. Avoid stacking mutually exclusive optionals on top of each other, that just wastes space. And ...



Top 50 recent answers are included