Benutzer:Rdiez/ErrorHandling - Versionsgeschichte

Rdiez: Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

2015-03-22T20:57:12Z

Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

Änderungen zeigen

Rdiez am 31. Oktober 2014 um 20:13 Uhr

2014-10-31T20:13:46Z

Rdiez: More about bash

2014-08-27T20:14:35Z

More about bash

Rdiez: More bash stuff

2014-08-26T18:58:54Z

More bash stuff

Änderungen zeigen

Rdiez: Microsoft VBA

2014-08-15T19:29:20Z

Microsoft VBA

Rdiez: bash errexit examples

2014-08-15T19:20:17Z

bash errexit examples

Rdiez: Link auf lwn.net/Articles/576478/

2014-08-15T18:54:32Z

Link auf lwn.net/Articles/576478/

Rdiez: Python 'with' statement.

2014-02-28T20:11:28Z

Python 'with' statement.

Rdiez: C++ exceptions may be unsafe in interrupt context

2014-02-28T19:54:55Z

C++ exceptions may be unsafe in interrupt context

Rdiez: Ein Abschnitt über Perl 6 eingefügt

2014-02-28T18:59:56Z

Ein Abschnitt über Perl 6 eingefügt

@@ Zeile 2.070: / Zeile 2.070: @@
   $ echo "Exit code: $?"
   Exit code: 0
 Finally, you should probably add a comment so that unwary programmers do not feel tempted to optimise such temporary variables away. For example:

@@ Zeile 1.871: / Zeile 1.871: @@
 and that will be too late.
-Shell scripting has so many gotchas that it is virtually impossible to get the error handling right. But nevertheless, here are a few things you should try.
+Nevertheless, it is worth pointing out that it is virtually impossible to get the error handling completely right in bash scripts.
 ==== Set the ''nounset'' flag ====
@@ Zeile 2.029: / Zeile 2.044: @@
   Hello!
-===== Use One Temporary Variables per $(tool) Expansion =====
+===== Use One Temporary Variable per $(tool) Expansion =====
 The ''errexit'' option does not detect errors properly if the command that fails is in a $(tool) expansion,

← Nächstältere Version		Version vom 15. August 2014, 19:29 Uhr
Zeile 1.822:		Zeile 1.822:

	When you close a listening network socket gracefully, the callback routine gets called, and when this routine calls EndAccept(), an exception is raised. That is, a graceful close is reported as an error, which is bad practice.		When you close a listening network socket gracefully, the callback routine gets called, and when this routine calls EndAccept(), an exception is raised. That is, a graceful close is reported as an error, which is bad practice.
		+
		+	=== Microsoft's Visual Basic for Applications (VBA) ===
		+
		+	All user-interface event handlers should be like this:
		+
		+	Public Sub SomeUiEventHandler()
		+
		+	On Error GoTo ErrorHandler:
		+
		+	... normal code here ...
		+
		+	Exit Sub
		+
		+	ErrorHandler:
		+
		+	Dim errMsgboxRes As VbMsgBoxResult
		+	errMsgboxRes = MsgBox("Error: " & Err.Description, vbOKOnly + vbCritical)
		+
		+	End Sub
		+
		+	You may want to factor out the error dialog code to a common routine, in case you want to improve the error dialog later on.

	=== Perl 6 ===		=== Perl 6 ===

@@ Zeile 1.849: / Zeile 1.849: @@
 if trouble
-That means that exit code 1 may not be considered an error in your shell script. You need to turn off the ''errexit'' flag temporarily for such tools. Alternatively, you can write a couple of helper functions that help save and restore that flag. Fortunately, such exit code deviations are rare.
+That means that exit code 1 may not be considered an error in your shell script. If that is the case, you need to turn off the ''errexit'' flag temporarily for such tools. For example, this code ignores any errors while reading a file:
 ===== Avoid the AND and OR Operators in Shell Sentences =====

@@ Zeile 179: / Zeile 179: @@
 Leaving a [http://en.wikipedia.org/wiki/Memory_leak memory], [http://en.wikipedia.org/wiki/Handle_leak handle] or [http://en.wikipedia.org/wiki/Resource_leak resource leak] behind is not an option either, because the application will crash or fail later on for a seemingly random reason. The user will probably not be able to provide an accurate error report, and the error will not be easy to reproduce either. The real cause will be very hard to discover and the user will quickly loose confidence in the general application stability.
-Some errors are just too expensive or virtually impossible to handle, especially when they occur in clean-up sections. An example could be a failed ''close( file_descriptor );'' syscall in a clean-up section, which should never fail, and when it does, there is not much the error handler can do about it. In most cases, a file descriptor is closed after the work has been done. If the descriptor fails to close, the code probably attempted to close the wrong one, leaving a handle leak behind. Or the descriptor was already closed, in which case it's probably a very simple logic error that will manifest itself early and is easy to fix.
+Some errors are just too expensive or virtually impossible to handle, especially when they occur in clean-up sections. An example could be a failed ''close(&nbsp;file_descriptor&nbsp;);'' syscall in a clean-up section, which should never fail, and when it does, there is not much the error handler can do about it. In most cases, a file descriptor is closed after the work has been done. If the descriptor fails to close, the code probably attempted to close the wrong one, leaving a handle leak behind. Or the descriptor was already closed, in which case it's probably a very simple logic error that will manifest itself early and is easy to fix. For more details about close()'s possible error codes, check out LWN article [http://lwn.net/Articles/576478/ Returning EINTR from close()].
 See section "Errors When Handling a Previous Error" above for other error conditions that could break the transaction semantics (the 'fully succeeded' or 'fully failed' rule). Leaving corrupt or inconsistent data behind is probably worse than an instant crash too. At some point during development of clean-up and error-handling code, you'll have to draw the line and treat some errors as irrecoverable panics. Otherwise, the code will get too complicated to maintain economically.

← Nächstältere Version		Version vom 28. Februar 2014, 20:11 Uhr
Zeile 1.828:		Zeile 1.828:

	I don't think this compromise really helps. A developer will always want the see the full call-stack, and an end-user will probably not benefit much from seeing an automatically-generated, ugly, partial call stack. The trait syntax does not appear to conveniently lend itself to internationalisation either. And the developer ends up having to maintain a second name or short description for many routines, which is tedious.		I don't think this compromise really helps. A developer will always want the see the full call-stack, and an end-user will probably not benefit much from seeing an automatically-generated, ugly, partial call stack. The trait syntax does not appear to conveniently lend itself to internationalisation either. And the developer ends up having to maintain a second name or short description for many routines, which is tedious.
		+
		+	=== Python ===
		+
		+	Python has the ''with'' keyword and ''__enter__'' und ''__exit__'' methods, in order to help factor out standard uses of try/finally statements.

	=== Shell Scripting ===		=== Shell Scripting ===

← Nächstältere Version		Version vom 28. Februar 2014, 19:54 Uhr
Zeile 797:		Zeile 797:

	Therefore, for the reasons above, I am not convinced that relying on old-style if() statements for error-handling purposes helps writing better code in the long run.		Therefore, for the reasons above, I am not convinced that relying on old-style if() statements for error-handling purposes helps writing better code in the long run.
		+
		+	==== C++ exceptions may be unsafe in interrupt context ====
		+
		+	The C++ standard mandates that it should be safe to copy exception objects as they get propagated up the call stack. The reason is that, in some compilers, throwing an exception is implemented in the same way as if the throwing routine had returned a C++ object to the caller. The throwing routine creates the exception object in its stack context, fills it with data, and then calls the ''copy constructor'' or ''operator='' in order to copy the object's contents to another instance in the caller's stack area. Before returning to the caller, the throwing routine destroys the local exception object instance as part of its stack clean-up procedure.
		+
		+	When returning C++ objects, the compiler is allowed to optimise away such copying, but that only works well between one caller and its callee. Exceptions can propagate up many levels, and it would be inefficient to attempt that kind of optimisation across big call trees, especially for exception objects, which should rarely be thrown.
		+
		+	Copying exception objects during call unwinding is slow, but predictable. It may be possible to optimise it by creating a separate memory area outside the standard call stack to hold the current exception object. Such an optimisation could get complicated if an exception is thrown while processing a previous one.
		+
		+	The trouble is, GCC's one and only C++ exception implementation follows a different approach: exceptions objects are created on the heap, and only a pointer to the current exception object is propagated up the call tree. That means that ''throw'' ends up calling ''malloc()'' behind the scenes. I would normally prefer the other "slow and predictable" strategy to GCC's "optimised" implementation, because the time it takes to execute a ''malloc()'' call is usually not deterministic. However, given that exceptions will almost always contain heap-allocated, variable-length strings for rich error messages, GCC's choice does not really matter much in practice. It may even be faster, although speed shouldn't be so important when processing exceptions.
		+
		+	There is a catch, though: if you are writing embedded software on a bare-metal environment, it may not be safe to call ''malloc()'' within interrupt context. Therefore, even if your restrict your interrupt handler to simple exception objects which contain only integers, throwing an exception may still be unsafe. In order to avoid nasty surprises in such restricted environments, you should make sure that your bare-metal ''malloc()'' implementation asserts that it is not running in interrupt context.
		+
		+	Even if you make sure that ''malloc()'' is still safe within interrupt context, the stack unwinding logic may not be reentrant or thread safe. You will probably find it hard to find any documentation whatsoever about your compiler vendor's stack unwinding implementation.

	==== Social Resistance ====		==== Social Resistance ====

← Nächstältere Version		Version vom 28. Februar 2014, 18:59 Uhr
Zeile 1.808:		Zeile 1.808:

	When you close a listening network socket gracefully, the callback routine gets called, and when this routine calls EndAccept(), an exception is raised. That is, a graceful close is reported as an error, which is bad practice.		When you close a listening network socket gracefully, the callback routine gets called, and when this routine calls EndAccept(), an exception is raised. That is, a graceful close is reported as an error, which is bad practice.
		+
		+	=== Perl 6 ===
		+
		+	Perl 6 introduces a 'user-facing' ''trait'' for routines, so that an associated message string appears in the call-stack dump for each tagged routine the exception propagates through. All other non-tagged routines do not come up in the call-stack dump.
		+
		+	I don't think this compromise really helps. A developer will always want the see the full call-stack, and an end-user will probably not benefit much from seeing an automatically-generated, ugly, partial call stack. The trait syntax does not appear to conveniently lend itself to internationalisation either. And the developer ends up having to maintain a second name or short description for many routines, which is tedious.

	=== Shell Scripting ===		=== Shell Scripting ===