Tag Info

New answers tagged

0

Well, you could sort of roll-your-own finally, using Lambdas, which would get the following to compile fine (using an example without RAII of course, not the nicest piece of code): { FILE *file = fopen("test","w"); finally close_the_file([&]{ cout << "Finally you close the file." << endl; fclose(file); }); } ...


1

If your exception did in fact contain any logic, I would take issue with it, but it does not, so I think it is fine. What it contains is the range (the set, actually) of accepted values, which is not a bad idea. (It might be unnecessary, because the range of accepted values is fixed and known in advance, but not bad at all.) I think that it should also ...


0

As you pointed out, often the specifics of what constitutes invalid request parameters is different enough for each view, and so including this type of code in each view is (I think) fine and not a DRY violation. It also self-documents the view by having code at the beginning that clarifies what the view expects to receive, either in the URL, GET, or POST, ...


0

Using an exception to be part of program-flow is an anti-pattern, they should not be used for things that you expect to happen - hence the name! I'd say that practicality trumps such rules however, but here I'd question why you are throwing such an exception and simply not returning the 405 result code - if the method succeeded you wouldn't throw an ...


3

Storing information related to the exceptional circumstance in the exception is definitely a good thing, as it can allow a handler to fix & retry or fail gracefully. It's not logic but data, so you don't have to worry about the exception class being too complex. If the exception took a route and extracted the supported methods, that would be getting too ...


1

what are cons of using ref varibales as parameter in service operation contracts ? I first wrote: "The major con is that this does not work. Period. You need another approach." It seems that that's not correct, as long as you don't leave the .NET environment, it seems to work. However, ref parameters are considered bad practice even in normal code by ...


3

Ultimately, it depends on the specification of the particular language that you are using, but in general, pass-by-value-result (Wikipedia) means that the original value of the caller will not be modified until the function returns, so the only reasonable thing to expect is that the value should remain unchanged in the event of an exception, because when an ...


-1

What makes you think the index value or the required range or the name of the table is a useful detail, for an exception? Exceptions aren't an error handling mechanism; they are a recovery mechanism. The point of exceptions is to bubble up to the level of code that can handle the exception. Wherever that level is, either you have the information needed, ...


0

Opening a connection performs a similar function to performing a ping. It will only succeed if you have connectivity. You will need to use an open port on each destination you wish to connect to. Port 80 may well be open. For faster response you will want to timeout failed connections fairly quickly.


0

To give a slightly different answer: The offending code has probably been done to spec: The function receives X and returns Y If X is invalid, throw exception Z Add the pressure to deliver exactly to spec (for fear of being rejected in review/testing) in minimum time and with minimum fuss, then you have your recipe for an entirely compliant and unhelpful ...


12

In this more recent question I made the point that exceptions should not contain a message at all. In my opinion, the fact that they do is a huge misconception. What I am proposing is that The "message" of the exception is the (fully qualified) class name of the exception. An exception should contain within its own member variables as many details as ...


0

While I do agree that exceptions should contain as much information as possible, or at least be less generic. In the table not found case, the table name would be nice. But you know more about what you were trying to do at the place in the code where you received the exception. While you often really can't do much to rectify the situation when something ...


0

Exceptions have a language- and implementation- specific cost. For example, C++ exceptions are required to destroy all the living data between throwing call frame and catching call frame, and that is expensive. Hence, programmers do no wish to use exceptions a lot. In Ocaml, exception throwing is nearly as fast as a C setjmp (its cost does not depend upon ...


1

First off, let me burst a bubble by saying even if the diag message is loaded with information that brings you to the exact code line and sub command in 4 seconds, chances are the users will never write it down or convey it to the support folks and you will be told "Well it said something about a violation... I don't know it looked complicated!" I've been ...


7

I don't have an excess of C# experience, or C++ specifically, but I can tell you this - developer-written exceptions 9 out of 10 times are more useful than any generic exception you will ever find, period. Ideally yes, a generic exception will point you to exactly why the error occurred and you'll be able to fix it with ease - but realistically, in large ...


144

Exceptions do not contain useful details because the concept of exceptions has not matured yet enough within the software engineering discipline, so many programmers do not understand them fully, and therefore they do not treat them properly. Yes, IndexOutOfRangeException should contain the precise index that was out of range, as well as the range that was ...


33

Why is it that many common exceptions from system components do not contain useful details? In my experience, there are a number of reasons that exceptions do not contain useful information. I expect that these sorts of reasons would also apply to system components - but I don't know for sure. Security focused people see exceptions as a source of ...


4

The question is specifically asking why do so many exceptions thrown by "system components" (aka standard library classes) not contain useful details. Unfortunately, most developers do not write the core components in standard libraries, nor are detailed design documents or other design rationale necessarily made public. In other words, we may never know ...


1

Null is evil. However, the lack of a null can be a greater evil. The problem is that in the real world you often have a situation where you do not have data. Your example of the version without nulls can still blow up--either you made a logic mistake and forgot to check for Goodman or perhaps Goodman got married between when you checked and when you ...


-3

NULL is a problem because it conceptually represents data that may or may not exist. Data that may not exist is assumed not to exist (because assuming the opposite crashes your program so you always have to assume the value could be NULL). Data that doesn't exist is not worth reasoning about, and is not very useful. If your program is mostly not useful, you ...


-1

In terms of correctness, I think exception handling is the way to go (I sometimes use the hasattr() approach myself, though). The basic problem with relying on hasattr() is that it turns violations of code contracts into silent failures (this is a big problem in JavaScript, which doesn't throw on non-existing properties).


0

You should return a 4xx error with a detailed description of the reason the request failed in the response body. Can't help with the Java implementation. In many Python frameworks you would throw a 4xx exception as soon as your code has determined that the HTTP request is going to fail and this is caught by the framework and returns a 4xx HTTP status ...


0

One way to handle these is to have factory functions: expected<Missile> Missile::Create(Params...) expected<unique_ptr<Missile>> Missile::Create(Params...) class Missile { private: Missile() = default; int Initialize(int power) // second phase constructor { // other operations (besides out_of_memory) that may fail // can ...


3

Default c++ constructors should be avoided if that means leaving object in a partially constructed place. This is obvious a good advice but things get complicated when you also disallow exceptions (as it does) Not necessarily. Consider these rules: a constructor should receive already validated arguments, and perform no operations outside of ...


0

Often the stack trace in an exception is of no value and in such cases no harm is done in throwing a new exception. If you don't know what happened you of course retain all the data you can for debugging purposes. However, in well-written code there will be few such exceptions, most exceptions will be because the program is a victim of outside forces. If ...


1

Depends If your method is doing something that will be visible to the end user, security becomes a concern. You should never throw low-level exceptions back to the user on distributed systems. Your catch() statement should encapsulate the low-level error and only write it to a (more) secure logging mechanism. One that is only easily accessible by support ...


7

Mandatory disclaimers (1) Because people who have seen the code can't say anything about it, and people who can freely comment on it have never seen the actual code, all we can do here is to speculate, speculate, and to speculate. Therefore, here is not an answer, just a speculation. (2) This is not the typical way I write C++ because most of the projects ...


2

There's something else here that no one has mentioned yet: Abstraction. Perhaps more importantly, leaky abstractions? Does it make sense to let your DataService throw an IO or Database exception? I'd say no, because it "leaks" the underlying implementation to the client code. Your FooController shouldn't care whether DataService is talking to a database ...


22

Providing more context information is always good. But there is an issue in the code that I wanted to point out (perhaps an issue with the API - the underlying exception class). You are not passing the root cause. Don't append e.getMessage() it may be redundant. Instead set the root cause like this catch(SameExceptionClass e) { throw new ...


3

Generally the rule for exceptions is, don't create a new exception type, and don't re-throw, unless you are sure that the caller is going to be able to do something different with the new information you provide (i.e. you are providing more information, such as a better error message, or you provide information to recover).


3

Throw the most specific exception that already exists. It does no harm to the caller who doesn't care and will just catch the more general common superclass, but adds useful extra flexibility to a caller that distinguishes between them. Be eager to change existing code from general → specific. It shouldn't break code, after all. Be wary of changing ...



Top 50 recent answers are included