ObjFW  History of src/exceptions/OFException.h of merge-in:2d82fdb

More than 16 is almost never useful, and 32 means it does no longer fit
on a 80x24 screen - or on the screen on a Nintendo 3DS or Wii. file: [c4d4a30786] check-in: [c272d187d7] user: js, branch: trunk, size: 3952 [annotate] [blame] [check-ins using] [diff]

This removes several initializers that omitted the errNo. Removing those
forces to think about whether there is a meaningful errNo to set instead
of just omitting it. file: [c52839786d] check-in: [4f36894ce7] user: js, branch: trunk, size: 3952 [annotate] [blame] [check-ins using] [diff]

Casts are now written like types in variable declarations. file: [4f8a3eb7a0] check-in: [4af49a13c3] user: js, branch: trunk, size: 3965 [annotate] [blame] [check-ins using] [diff]

Forgot to add 2017, even though I already did quite some changes in
2017. file: [a76e5557c3] check-in: [44f45c2e35] user: js, branch: trunk, size: 3906 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [494bdecd1c] check-in: [cec0f072f8] user: js, branch: 0.8, size: 3896 [annotate] [blame] [check-ins using] [diff]

While at it, also update the mail address. file: [abdb2b2934] check-in: [2a27cf3000] user: js, branch: trunk, size: 3900 [annotate] [blame] [check-ins using] [diff]

The old behaviour where the exception would access errno directly on
creation of the exception was very fragile. The two main problems with
it were that sometimes it would pick up an errno even though none had
been set and in other cases that when the exception was created errno
had already been overridden.

This also greatly increases errno handling on Win32, especially in
conjunction with sockets. It can still be improved further, though. file: [81451deb50] check-in: [62e2de30b9] user: js, branch: trunk, size: 3823 [annotate] [blame] [check-ins using] [diff]

This mostly removes the argument for the class in which the exception
occurred. As backtraces were recently added for all platforms, the
passed class does not give any extra information on where the exception
occurred anymore.

This also removes a few other arguments which were not too helpful. In
the past, the idea was to pass as many arguments as possible so that it
is easier to find the origin of the exception. However, as backtraces
are a much better way to find the origin, those are not useful anymore
and just make the exception more cumbersome to use. The rule is now to
only pass arguments that might help in recovering from the exception or
provide information that is otherwise not easily accessible. file: [2464e12597] check-in: [3d16a30f41] user: js, branch: trunk, size: 1379 [annotate] [blame] [check-ins using] [diff]

With this, neither the buggy __builtin_return_address() nor the GNU-only
backtrace() are required for a backtrace. file: [cc67cf334c] check-in: [259f593244] user: js, branch: trunk, size: 1936 [annotate] [blame] [check-ins using] [diff]

The reason is that __builtin_frame_address(n) for n > 0 seems to just
crash on most platforms when -fomit-stack-pointer is specified, which
seems to be the default for many platforms on -O2. The documentation
says that __builtin_frame_address() should return NULL in case it can't
get the frame, but it seems to crash instead.

Therefore, this commit reverts to using backtrace() from execinfo.h, if
available. However, as __builtin_frame_address() seems to always work on
PPC (even with -fomit-frame-pointer) and seems to be the only way to get
a backtrace on the Wii, this is still used if backtrace() is unavailable
and __ppc__ defined. file: [3edc7f9b6e] check-in: [f2a8bdf254] user: js, branch: trunk, size: 1912 [annotate] [blame] [check-ins using] [diff]

Instead, __builtin_return_address() is used now. This makes backtraces
available on many platforms, it even works if dladdr is missing (it does
not show symbol names then, though). file: [a50325ba8b] check-in: [a889f21180] user: js, branch: trunk, size: 1897 [annotate] [blame] [check-ins using] [diff]

This also removes "bool *stop" from some blocks where it does not make
sense. file: [20ad317438] check-in: [e8473b9db8] user: js, branch: trunk, size: 1631 [annotate] [blame] [check-ins using] [diff]

This was pretty pointless, as it's usually only used once. file: [8f2a6df5f9] check-in: [d9ddc4d06e] user: js, branch: trunk, size: 1631 [annotate] [blame] [check-ins using] [diff]

This is safe as an "exception loop" can't happen, since if allocating
an exception fails, it throws an OFAllocFailedException which is
preallocated and can always be thrown.

So, the worst case would be that an autorelease of an exception fails,
triggering an OFOutOfMemoryException for which there is no memory,
resulting in an OFAllocFailedException to be thrown. file: [a8b41d395b] check-in: [e1e7ffa903] user: js, branch: trunk, size: 1466 [annotate] [blame] [check-ins using] [diff]