New answers tagged

2

The fellow who designed the system before I came here included a "Unit of Work" object that could hold a result of the async operation (a Type T) and any errors that occurred, including exceptions and stack traces. That said, I'm not exactly a fan of his architectural style; it is too complicated, and I have my doubts about the effectiveness of putting ...


0

I may say that the issue isn't fixed but is closed as non-reproducible. Yes but I still couldnt understand this line: " In the case of a non-static method becoming static this will cause the interpreter to read a value of the stack which isn't guaranteed to be valid." Most likely the point is that in the case of static method top cell of the stack is ...


0

Crashing gracefully is a good thing most of the time -- but there are trade-offs. Sometimes it's a good thing to crash. I should mention that I'm mostly thinking about debugging in the very large. For a simple program -- although this might still be useful, it's nowhere near as helpful as it is with a very complex program (or several complex programs ...


20

I have a question regarding the use of exceptions at the highest level of a program. I have seen programs using this strategy and I have also seen posts considering this bad practice. However, the posts considering this bad practice have been written in c# or some other programming language, where there are some error handling built in. ...


6

Clearly in your main () function you don't have a chance to handle the exception in any meaningful way. If an exception reaches main (), all you know is that something went badly wrong. You can of course decide how you want to handle the situation that "something went badly wrong". That's not at all a bad practice. You may of course decide that you handle ...


2

You've chosen an unusual architecture. What you are calling a stack machine isn't really what we typically call a stack machine. A stack machine is a type of computer architecture. Since your stack machines cannot execute a program, they aren't an instance of computer architecture, and thus what you are implementing is not properly a stack machine. But, ...


10

TL;DR: What does the specification say? A technical detour... When an exception is thrown and no handler is ready for it: it is implementation defined whether the stack is unwound or not std::terminate is called, which by default aborts depending on your environment setup, aborting may or may not leave a crash report behind The latter can be useful ...


20

One problem with letting exceptions go past main is that the program will end with a call to std::terminate which default behavior is to call std::abort. It is only implementation defined if stack unwinding is done before calling terminate so your program can end without calling a single destructor! If you have some resource that really needed to be restored ...


4

The moment you know you have to abort, go ahead and call std::terminate already to curtail any further damage. If you know you can wind down safely, do that instead. Remember that stack-unwinding is not guaranteed when an exception is never caught, so catch and rethrow. If you can safely report/log the error better than the system will do it on its own, go ...


4

An exception that you catch gives you the opportunity to print a nice error message or even try to recover from the error (possibly by just re-launching the application). However, in C++ an exception doesn't hold information about the program state when it was thrown. If you catch it, all such state is forgotten, whereas if you let the program crash, the ...


-6

Ultimately, if an exception bubbles up past main(), it is going to crash your application, and in my mind an app should never never crash. If it is ok to crash an app in one place, then why not anywhere? Why bother with exception handling at all? (Sarcasm, not really suggesting this...) You might have a global try/catch that prints an elegant message ...


26

The main reason for not letting exceptions escape from main is because otherwise you lose all possibility to control how the problem gets reported to your users. For a program that is not intended to be used a long time or distributed widely, it can be acceptable that unexpected errors are reported in whatever way the OS decides to do it (for example, ...


0

If you assign a custom error handling function to sys.excepthook, it will be called whenever an exception is raised and you won't need to use a try-except statement. Something like this should work: import sys def on_error(etype, value, tb): if etype == KeyboardInterrupt: return # handle other types of errors sys.excepthook = on_error


5

In general, you should not use except:, except for a few extremely rare circumstances, most notably log-and-reraise, or at the very top-level after which the program must end. Do not use it in libraries, or any non-top-level method, at all. Instead, please use except Exception:. It catches most 'normal' errors, except a few special ones (KeyboardInterupt, ...


0

data provided by an user is somehow incorrect and could cause my domain object to get into invalid state. So a subclass of DomainException extends RuntimeException is thrown. Perfect. Now: how should I handle this? Suppose my endpoint is used by a frontend and I want to display a proper message to user. Catch the runtime exception at the fault ...


4

Just rethrow the exception when you get it: try: #do stuff except KeyboardInterrupt: raise except: #do other stuff You specify that you get an exception that you know that you want to handle differently than default case, but you don't know how to handle it - so you just pass it, by throwing it again. Some working example: #!/usr/bin/python2 if ...


-2

And this is why I like Java - no such surprises there (every function explicitly tells you what Exceptions it might throw). Wouldn't that be something like this? try: #do stuff except(KeyboardInterrupt): pass else: #handle error


1

There is no global solution that just sets the problem variable to NULL and continuous on with normal program flow. This appears to be the only way: try: variable=values[5] except: variable='error' You'll have to change the original one liner to a 4 liner everywhere you use a list variable. It is the most appropriate way since it allows specific ...


0

The Service layer can translate exception received from lower layers to avoid coupling between the controller and the persistence layer. But in doing that translation, the Service layer should not throw away/obscure information that could be relevant for dealing with the reported error. So, the Service layer should in general have a one-to-one mapping ...


0

In most applications, the Service would retrieve the object it needs through the data access layer (effectively loading it in memory) before it can modify it and save it back. If the object doesn't exist, the data access object would probably return null. I would maybe not raise an exception at that point but at least return a specific error case value. The ...



Top 50 recent answers are included