-
I think that one additional benefit of this approach is, that things that as a senior dev seem obvious and don’t seem to need documentation or commentary, might not be as straightforward as thought and the reviewer can help to point that out by questioning the approach.
It’s a win-win because as a seniority progresses one might loose the view of what the presumable status quo is. In the time before becoming a truely senior dev, I tended to over complicate things however learning later, that the real solution could be much more simple. When a junior points out that things are quite complicated, it might be a good pointer to revise the code to be more straightforward. This in turn should or could lead to a better understandable code base.
-
evilissimo
5 months ago
|
link
| on:
Clang seems to be generating more user-friendly error message than gcc
Since the beginning clang was generating better error messages
GCC got better since though
-
I wonder how failing code in serverless environments differs from code that fails in “serverful” environments According to the logic of the post that implies that there is something new that is required. TBH I can’t see the point
To some extent I agree, however if there is too much code in the constructor it also is quite often an indicator that the code should be refactored. The convenience of what the RAII principle is providing allows also to avoid coding and resource management mistakes/bugs. In c++ exceptions are considered to be used for exceptional circumstances, and they are quite expensive for binary size, at least I made that experience when I used to work on some bigger applications. On the other hand I have been writing a lot of python code in the last few years and exceptions are the defacto way to handle errors. And it’s very much not a problem to use exceptions for non exceptional use cases.
In C++ I rather would argue that the approach of acquiring resources during initialization makes sense because it reduces your need for introducing checks that could lead to wrong code paths especially in the destruction. When applied correctly your program will be more robust if you use the raii principle. I recommend reading the exceptional C++ books by Herb Sutter those are very much still one of the best sources in writing C++ code that is handling exceptions properly.
Complexity in constructors and destructors is something to avoid which is something as I understand is your main criticism to the principle.
Agreed. Many dynamic programming problems are a good fit for backtracking with longjmp/“exceptions” which is how you’d write it in assembly anyway.
Lately (well, sometime in the last couple decades) I’m thinking “exceptions” aren’t a good use for exceptional situations either. That is to say, we’re using exceptions exactly backwards.
One of the best examples I’ve come up with is the out of disk space error. When you’re out of disk space, many programs will give up/crash – but consider the ergonomics of a CAD or video editing tool, that upon save starts moving this multi-gigabyte asset out to disk over what’s perhaps several minutes and then – oops! that partition is full.
If we unwind, the (temporary) file needs to be cleaned up(deleted), the user informed to make room somehow – none of these tasks are straightforward – all the file opens to save this large asset need to be in on it, which is often tricky if the file-saving was done by a different team than the UI team (who handles the exception, and thus deletes the files).
But what if we use a handler? We call the handler, from deep in the file saving code, and tell it “we’re out of disk space”. We can easily offer a callback to “retry”, and a list of any (temporary) file created so far so that they can be deleted (or moved onto another disk, or whatever). This could be provided by the UI team, but if not the operating system could have a crude “abort retry fail” dialog. We live in a multitasking world these days, so that’s probably good enough for a lot of enterprise applications – use goes and moves those files around and then resumes the save (by returning from the handler).