Exceptions, Go to Hell!

[RB]

Daniel T. wrote
If we were attempting to open a file, then it was absolutely necessary
for program continuance. Failure meant the program was broken.

( Please forgive me for even jumping in this thread, I don't mean to be
intrusive, especially since both of you are far above my level of programming
ability. But what the hell, I can learn only so much by sitting quietly at the
sidelines.)
But specifically "if it was absolutely necessary for this one file" well yes in
that one scenario it would mean continuing was futile but it would not in all cases
mean the app was broken, but rather the file format or pathname was broken or
corrupted. However "many" applications are written that utilize more than
"one" file. And you wouldn't want to shut down the app from underneath the
user in that case without giving them the option of "opening a different file" or
additionally utilizing the exception vehicle for backing out and resetting a filename
back to "untitled" so the user doesn't inadvertently overwrite the traversed set
filename that is current. At least I would not. Even if the file was the wrong format
or even corrupt it might have important data that could be salvaged in a dump and
the user would not want to inadvertently overwrite it next time they chose file save
not realizing it was still set to the old traversed filename This is something Goran
saved me from my ignorance on some time back.
Admittedly there are cases for sure that a shut down with hopefully a snapshot
report are in order, but not usually for opening a file or a network access failure.
In summation both of you have honed this subject done to many illuminating
pro's and con's of the aspect and I have enjoyed following it along.

 

[Goran Pusic]

If we were attempting to open a file, then it was absolutely necessary
for program continuance. Failure meant the program was broken.

So, you were signaling "program bug" failure using exceptions? That's
__not__ what you use exceptions for.

(Exceptions are __not__ a means of handling bugs in code, or at least
not a general-purpose one; e.g. there's no way to "handle" UB with
exceptions, not in any general sense of the world).

Goran.

 

[RB]

Goran Pusic
So, you were signaling "program bug" failure using exceptions? That's
__not__ what you use exceptions for.
( Exceptions are __not__ a means of handling bugs in code, or at least
not a general-purpose one; e.g. there's no way to "handle" UB with
exceptions, not in any general sense of the world ).
Goran.

Well wait minute, Master, if I may, I can rationalize what you are saying
to a point ( I know you and Joe and are pretty much the same on this )
but there are times that "testers" are not going to catch every single bug. I
have a co worker in my cad department and her husband is a programmer
for medical software. I have heard that projects go out the door in some
scenarios (due to various deadline, economic or otherwise pressures) and
they sometimes know there are bound to be some bugs still in the code. (yea
that sounds scary I know for medical, but that's life on planet earth) Wouldn't
it be prudent to have exception frames to at least cover a crash report so it
could be rectified down the road ?
Or did I miss your context all together again ?

 

[Goran Pusic]

I have a co worker in my cad department and her husband is a programmer
for medical software. I have heard that projects go out the door in some
scenarios (due to various deadline, economic or otherwise pressures) and
they sometimes know there are bound to be some bugs still in the code. (yea
that sounds scary I know for medical, but that's life on planet earth) Wouldn't
it be prudent to have exception frames to at least cover a crash report so it
could be rectified down the road ?

I am not sure what you mean by "exception frames", not unless if you
think about details of implementation of exceptions for some platform
(which you seem to have done here before), but I guess you mean
something like "let's have an exception if code hits a bug".

If so, yes, perhaps, but that has very limited use. E.g. if your code
invokes undefined behavior (e.g. it overflows a buffer), any attempt
at signaling anything might with an exception might be futile. In my
experience, once UB happened, code is dead in the water. Even if code
ran for hours after.

But if e.g. code stumbles on a NULL pointer where there should be
none, it could throw e.g. a runtime_error with no harm. That case, a
case of precondition violation, if you will, could work, provided that
it's checked in every place it could have any influence on correct
operation. If not...

So... I agree that testing will never catch all bugs, but attempting
to catch them at runtime IMO does not help. IMO, if a bug (especially
UB) appears, I am lucky to crash as quickly as possible. And as you
might remember, to me, a crash != exception, not in C++ sense.

Goran.

 

[RB]

Goran Pusic"
I am not sure what you mean by "exception frames", not unless if you
think about details of implementation of exceptions for some platform
(which you seem to have done here before), but I guess you mean
something like "let's have an exception if code hits a bug".

But if e.g. code stumbles on a NULL pointer where there should be
none, it could throw e.g. a runtime_error with no harm. ....< cut >
... could work, provided that it's checked in every place it could have
any influence on correct operation. ........< > .........

So... I agree that testing will never catch all bugs, but attempting
to catch them at runtime IMO does not help..................< >
And as you might remember, to me, a crash != exception,
not in C++ sense.

Oh well, sorry for ambuity, I don't necessarily mean use exceptions for error
checking (persay, though sometimes that statement in some areas to me seems
to denote splitting hairs). But (in addition to previous said issues that occur
outside the realm of a bug) I was referring to (as you replied ) where the math
ceilings, floors or zero values were not covered like they should have been.
Say it's in a value realm that does not normally traverse and is somehow not
caught during testing.
Or an illegal address ptr access turns up. Now granted this is a error on the part
of a programmer (am I wrong ? ) since I have coded my own dummy self many
times to protect against ptr address areas (that change address during runtime)
from coming up illegal or even outside the stack. But I would think one would want
to have all the information they can reported back so as to solve their foo bar before
they become unemployed ? Even if you had a near omnipotent handler code in place
to allow for continued execution by resetting the context of the voilating address,
I would think you would still want to know about it.
Specifically some sort of base paradigm (third party) or maybe some simple
thing in like,

// in header file
// ( below type in winbase.h )
static LPTOP_LEVEL_EXCEPTION_FILTER m_prevFilter;

// in cpp file
CMissedSomething :: CMissedSomething( ) // Constructor
{ // Install SEH unhandled exception filter function
m_prevFilter = SetUnhandledExceptionFilter(MyUnCaughtFilter);
.............
// Check some stuff
..........
// send the context and whatever else needed to file and or email and
// hope to God our robotic heart surgery software hasn't killed someone
// before we get this dump.
}

Covering ( reporting an uncaught SEH exception ) the entire app. Obviously this
base setup could not handle inner exception area correction or object destruction
and heap deletetions (without adding inner C++ E frames in said areas ). And
admittedly even this could not catch all errors (that did not cause an SEH exception)
but to me this seems like a step in the right direction. But even say the omnipotent
handler could also call the into a report class (separate from MyUnCaughtFilter) and
still issue a report even if execution continues by resetting the illegal access context to
a legal address ( if said legal reset doesn't cause bad data down the road ).
Again "all" exceptions whether Hardware (divide / 0, etc) or software (RaiseException)
are implemented through the same base understructure. The C++ compiler uses this
same understructure while extending it's capability, albeit it does not attempt to cover
ascyncronous (SEH ) tracking. But once you get past the unwinding and object
destruction differences it all comes down to a raised exception.
Anyhow just my view looking out from my learning portal and listening to the pros.
No need to reply if I am too ambiguous but thanks for the thread because it has helped
me conceptualize what I have been studing for awhile.
Oh and by the way I bought the Exceptional C++ you mentioned. I went to Amazon
and got it used for $14 bucks. Can't beat that.
My compiler won't acknowledge exception specifications so I could not disassemble
it to see what it was doing. But after reading the online text of Sutter I was able to see
that when an exception specification says it won't throw anything, it is actually lying.
Rather the truth is the compiler (if it acknowledges said spec) puts in the catch blocks
for you and many times you actually end up with more try catches than if you had typed
them yourself while deciphering where you needed them. Most compilers have
disregarded this specification.

 

[James Kanze]

Well wait minute, Master, if I may, I can rationalize what you
are saying to a point ( I know you and Joe and are pretty much
the same on this ) but there are times that "testers" are not
going to catch every single bug. I have a co worker in my cad
department and her husband is a programmer for medical
software. I have heard that projects go out the door in some
scenarios (due to various deadline, economic or otherwise
pressures) and they sometimes know there are bound to be some
bugs still in the code. (yea that sounds scary I know for
medical, but that's life on planet earth) Wouldn't it be
prudent to have exception frames to at least cover a crash
report so it could be rectified down the road ?

Or did I miss your context all together again ?

An assertion failure will, or should, generate all of the
necessary information for debugging. That's why systems provide
different means of terminating a program. When you find a bug
in the code, however, you should terminate the program as
quickly as possible, doing as little extra work as possible.
Partially, in fact, to ensure that the information about the
crash does correspond to the actual context where the crash
occured. In the case of critical systems, to get out of the way
so the backups can take over. And in all cases, because if the
program is corrupt, who knows what it will do when unwinding the
stack.

 

[James Kanze]

On Aug 26, 1:28 pm, James Kanze <[email protected]> wrote:

[...]

Yes, but do you know one where it is on and can not be turned
off?

I've known some in the past. (At least one has evolved to make
overcommit optional, turned off by default. And I think it can
be turned on at a process by process level, which is
a reasonable option.)

Linux is most widely accessible OS that has overcommit so
i gave it as example. Imagining OS that has overcommit
unavoidable i have to overtake memoy management/allocation,
take large chunk and fill with random numbers to be sure it is
mine. Using problematic platforms has a cost.

Yes. Where I was working at the time, our solution was to not
use them. Anytime you're doing something serious, which has
to work, then you cannot permit overcommit.

The ones i have some experience with had it set 0 by default.
I have quite limited experience with Linux so i do not know,
but having it on by default sounds like having some "run
unreliably" setting turned on by default.

If vm.overcommit_memory == 0, Linux uses "heuristic overcommit
handling", whatever that means (but it does mean
overcommitting). 1 means always overcommit, and 2 means don't
overcommit. If vm_.overcommit_memory is anything but 2, your
system is unreliable. (On the other hand, you may be able to do
more with it if it doesn't crash. Some programs do allocate
large blocks of memory that they don't fully use.)

 

[Kai-Uwe Bux]

Well... I __guessed__ that OP who complained about try/catch had too
many of them (perhaps I was wrong), and that they were caused by the
following situations:

{
TYPE r = alloc(); // r holds a resource; we must free it at the
block end.
workworkwork(); might throw, or simply return prematurely
free(r);
}

so you'd do:

{
TYPE r = alloc();
try
{
workworkwork();
free(r);
}
catch(...)
{
free(r); // must be a no-throw operation.
throw;
}
}

This alone is ugly, now imagine that you have another (or more)
resources in that block.

So, if you use RAII (that is, have resource-wrapper class for TYPE),
or scope guard, try/catch-es like above all disappear (as well as
multiple calls to free).

I see, you worry about the catch block that is not concerned with actually
dealing with the exception thrown by workworkwork(). That's why you rethrow.
You still need to catch the exception from workworkwork() and handle it
proper. What RAII gives you is automatic resource management during stack
unwinding.

The number of "other types" of try/catch statements in code is IMO
very, very small. And the bigger the code base, the smaller it is
(compared to said size).

Hm, I am not so sure about that. It very much depends on how religiously and
locally you handle exceptions. On one extreme end, you let everything
propagate to the top-level and have one catch-all block. On the other end of
the spectrum, you can handle each exception as early as possible. In the
later case, you will still have a sizable number of catch blocks.


Best

Kai-Uwe Bux

 

[joe]

Well wait minute, Master, if I may, I can rationalize what you are
saying to a point ( I know you and Joe and are pretty much the same on
this )
but there are times that "testers" are not going to catch every
single bug. I have a co worker in my cad department and her husband
is a programmer for medical software. I have heard that projects go out
the door in
some scenarios (due to various deadline, economic or otherwise
pressures) and they sometimes know there are bound to be some bugs
still in the
code. (yea that sounds scary I know for medical, but that's life on
planet earth) Wouldn't it be prudent to have exception frames to at
least cover a crash report so it could be rectified down the road ?
Or did I miss your context all together again ?

(I tried to be brief below, surely at the expense of being entirely
"correct". I started writing a paper once on the topic, but never pursued
it to the end and have it reviewed and published. Surely what is below is
muchly the same as some of the topics in the paper, albeit just thoughts
off the top of my head at this time in reply to the topic at hand in this
thread and in reply to the post above).

Two things first. Errors and bugs are different animals. Exceptions (or
return codes or ...) can help you manage the former, but not the latter.
Assertions help with the latter, but not the former. Errors are dealt
with in released software and are expected. Bugs are (attempted to be)
removed during development time and are "unexpected" in released
software. Many errors can be "fixed up" during running and indeed that is
what error "handling" is all about: thinking about all the possibilities
and doing contingency planning. I don't have any example of bugs being
fixed up on-the-fly in a running program.

That said, the assumption that there can be "an all powerful exception
handler" that can catch anything (errors, bugs) you failed to address in
your code, is erroneous. Realize that if there was nothing to raise an
exception in the first place, then you can't handle it, so you won't be
able to handle that null ptr that you didn't assert on during development
of the software (maybe an OS will "have the final say" about it). The
program is going to crash. If that kind of thing cannot be tolerated,
then you have to use something out-of-band (OOB) (to hijaack a term from
the comm world). Redundancy (in software or hardware or complete systems)
is just one technique of fault tolerance. Not every system or program
needs that level of fault tolerance.

What is appropriate depends on the application and type of
program/system. Consider how a desktop application program may fault and
produce a messagebox to the user indicating that the program WILL
terminate (maybe it will save your work, maybe it won't or maybe it has
been saving it all along) and offer to send a bug report to the developer
so they can release a patch to fix the bug. The generated messagebox was
the result of an assertion failure. Had the assertion not been there and
retargeted in release mode, the program would have crashed, and programs
do crash and in a desktop program the OS would have saved the rest of the
system from failing.

So, there is no "easy answer/silver bullet" in regards to error
"handling" strategy and tactics. "Strategy" is the big picture (What kind
of software program is it? What level of fault tolerance is required?
What will be tolerated by users?) whereas "tactics" are the details and
localized stuff (Should I return an error code from this function or
raise an exception? Should errors be logged? Is a messagebox OK? Should
an administrator be notified?). There is a lot to thing about while
writing software and up front planning is required. In order to do that
up front planning, though, one has to be well-versed in the principles
and techniques.

 

[RB]

Kai-Uwe Bux wrote
I see, you worry about the catch block that is not concerned with actually
dealing with the exception thrown by workworkwork(). That's why you rethrow.
You still need to catch the exception from workworkwork() and handle it
proper. What RAII gives you is automatic resource management during stack
unwinding.

Please excuse if I may also reply. I am just now studying RAII and have not
gone into the depth with it as I have with the exception mechanism. But it appears
that what you are saying is that, granted he would not have to worry about the since the wrapped resoures in the RAII class object would go out of scope
(be destructed ) when the calling function finished. I get that part, so then
your are further saying that " if " there are other ramifications involved other
than freeing resources and destructing objects he would have to handle the
exception. Well yes I agree and Goran must have been focusing on the
resource freeing only in this scenario since I know he is well aware of such
other ramifications since he was the first to point them out to me some time
back in the area of file access and exceptions.
Possibly the ScopeGuard ( third party ? ) helps in this area. Anyhow in his
time zone it will be some hours before we can get a reply on that.

On one extreme end, you let everything propagate to the top-level and have
one catch-all block. On the other end of the spectrum, you can handle each
exception as early as possible. In the later case, you will still have a sizable
number of catch blocks.

Is there one rule for this ? It would appear to me that one would want to
place try / catch blocks in the function that holds objects you want destructed
in case of an exception ( if you were not implementing RAII ) and otherwise
at a position that would be at a point where code that would rectify "other
ramifications " ( besides resource management ) could execute prior to
other continuing code?
Please point out the any concept I have missed in that assumption.
And again I totally agree with the concept that " if " no exception blocks are
necessary (for varied reasons) then none should be there. Exception blocks
should never be used casually to replace all error checking and/or handling.
Of course this whole thread has been about the gray area in between.

 

[RB]

joe wrote
(I tried to be brief below, surely at the expense of being entirely
"correct". ............ <cut >..................................
Two things first. Errors and bugs are different animals. Exceptions (or
return codes or ...) can help you manage the former, but not the latter.
Assertions help with the latter, but not the former. ........< >............
So, there is no "easy answer/silver bullet" in regards to error
"handling" strategy and tactics. "Strategy" is the big picture (What kind
of software program is it? What level of fault tolerance is required?
What will be tolerated by users?) ...........< >.................

Thanks joe
And by the way in my posted statement of I was referring to Joseph Newcomer not you. But none the less I thank
you for the very informative and detailed reply. I read it over and thoroughly.
I have only one question. Could you give me a brief (if possible) description
of what a Bug is, since I now know it is not an error.

 

[joe]

Well, I am not so sure about that. To me, exceptions are a way to
__structure code in face of unexpected situations__.

"exception handling" = "error handling". There is no difference when used
like that. Exceptions are C++ machinery to assist in "error handling".
The kinds of errors that machinery was designed for are definitely
EXPECTED.

They are not
there to "handle errors",

Yes they are, that is the intent: to keep a program running and only
bugout as a last resort.

and they are certainly not there to somehow
handle __coding errors__ (that's IMO a massive error many people
make).

Right, debugging is a separate area of concern in software development.

And indeed, if you look at your OS, it does __not__ emit any
exceptions in C++ sense (nor in any other language sense, really). Not
even Windows does that. When you receive windows exception (SE one),
your code is already dead.

Asynchronous errors?

Effectively, exceptions help you to eliminate a myriad of error code
paths and transport error info to a place where you can do something
about that error. No more, no less.

I tend to view the whole schmere of the C++ exception machinery as a
propagation technique only also. But, whatever propagation technique is
used, the goal is (should be) handling of the errors. Of course one must
identify the errors first, so maybe you are just thinking about a subset
of them.

In a way, when speaking about
exceptions, I often say "forget error __handling__, there is no such
thing". Because, what we call error handling, exceptions or not, is
almost always "clean up and get out, report error to some external
factor".

"Clean up and get out" sounds like being lazy with the handling thinking.
Thinking about handling errors will necessarily flesh-out an otherwise
skeletal piece of software, read, affect it's design. "Clean up and get
out" as the predominant strategy is closer to assertion-checking than EH,
IMO.

It's _resource handling_ (and sometimes, program state
handling), on one hand, and _error reporting_, on the other. 'cause,
situations where error happens and code can correct it, are __rare__.

Perhaps you are focusing just on the errors that WILL result in
termination and not thinking about all the other errors that can happen
and can and should be handled successfully without termination?

And that's the ultimate reason why exceptions are so good - they help,
massively, in handling common situation where, upon error, all you can
do is to clean up and get out.

Or, perhaps you are focusing just on those errors that will likely
propagate across multiple levels? I don't distinguish between
"exceptions" and "errors", that's just terminology that means the same
thing IMO.

 

[joe]

Thanks will do that soon.



Well I totally agree with your above sumation, BUT what I was
attempting to say was "all " of the exception ability (even c++ ) is
created
(albeit expanded) on top of the basic provided by the hardware
interrupt system and OS

Not at all. Those are asynchronous/OOB errors and the C++ machinery is
not designed to interact with that.

partnership of the linked list of handlers at FS:[0]. That said I was
stating the
"origin" of said capability was (as I see it ) the promotion of a
more stable computer product (or least an informed exit ) as opposed
to an unlabeled crash.

And indeed, if you look at your OS, it does __not__ emit any
exceptions in C++ sense (nor in any other language sense, really).
Not even Windows does that. When you receive windows exception (SE
one), your code is already dead.

Well no I must have been ambiguous, since I did not mean that the OS
would implement an exception frame that would comply with the trylevel
and
scopetables of the C compiler's SEH

SEH is a Microsoft thing that is orthogonal to C++ exceptions.

 

[joe]

Thanks joe
And by the way in my posted statement of
I was referring to Joseph Newcomer not you.

I know that, silly.

But none the less I thank
you for the very informative and detailed reply. I read it over and
thoroughly. I have only one question. Could you give me a brief (if
possible) description of what a Bug is, since I now know it is not an
error.

Are you trolling? Anyway, Google it and Wikipedia it for all the details.
You'll find that the first one was actually a moth and hence the term
"bug".

 

[RB]

joe wrote
Not at all. Those are asynchronous/OOB errors and the C++ machinery
is not designed to interact with that.
SEH is a Microsoft thing that is orthogonal to C++ exceptions.

Well apologize again if I was ambiguous, but I did not say that C++
(trylevel only, syncronous) exception frames were designed to work (persay)
with SEH (trylevel and scopetables asyncronous).
Again to try and make it clearer, " all " exception mechanisms in a
MS VS windows app (with the exception possibly of NET JIT code, I
don't know about that ) run on ( but expands beyond ) the basic Frame
handler chain found at FS:[0] . Granted the compiler adds much more
unwind and trylevel code but it all functions on top of the basic chained
system of installed handler frames at FS:[0]
You can have both in the C++ exceptions and SEH exceptions in the same
program but the compiler won't let you have both in the same function.
In fact every windows app (mfc included ) has an SEH _try and _except
in the WinMainCRTStartup( ) code to cover the call to your compiler's
winmain (or console main ) function. This covers the whole windows app
for any SEH exception if not handled by your app's code. This CRT startup
function is where the final handler ( the Unhandled Exception dialog
with an option to send to MS ) kicks in " if " you have not handled it before
it gets to there. If you have not handled it with a specific C++ ,
catch( DivideByZero& E ) or a catch(...) or an SEH _except or with
SetUnhandledExceptionFilter( YourCustomFilter);
This CRT startup is in every MS VS windows app whether you use
C++ try catch or not or use both SEH in one function and C++ another.

Here the difference in stack frames
MS VC C++'s (try catch) Frame
ebp-C [ebp-C] [ebp-8] [ebp-4] [ebp-0] ebp-0
| PrevFrame|Handler | TryLevel |CallerEBP | FrameEBP
Frame-> [Frm +0] [Frm+4] [Frm+8h] [Frm+Ch] <-Frm+Ch

MS VC CRT's (SEH _try _except) Frame (also CRT final handler)
ebp-10 [ebp-10] [ebp-C] [ebp-8] [ebp-4] [ebp-0] ebp-0
PrevFrame | Handler|ScopeTable|TryLevel|CallerEBP|FrameEBP
Framer->[Frm+0] [Frm+4] [Frm+8h] [Frm+Ch] [Frm+10h]<-Frm+10h
Scopetable[0] PrevTryLevel: @ FFFFFFFF (always preceeds a trylevel 0)
CRTFilterFunc: @ 00401CA8 (depends on compile)
CRT__except block: @ 00401CC3 (depends on compile)

Win32 OS system final Handler's Frame (the basic frame) covers all processes
started and will surface when say an assembler program with no CRT startup
has an exception.
| PrevFrame|Handler |
Framer->[ Frm+0] [ Frm+4]

If a compiler (or you if you write your own custom handler) wants to do
exceptions on win32 it must play by the frame rules since when an exception
occurs the system walks the chain and calls each (and every handler ) up until
a handler is found that will handle the exception, when that is found based on
it's return, the system then calls each frame again ( if it is on the stack below
the frame that agreed to handle the E ) with the flag set to unwind.
--------------------------------
// pasted right out of my version of CRT0.C //
wWinMainCRTStartup()
{
/*
* Guard the remainder of the initialization code and the call
* to user's main, or WinMain, function in a __try/__except
* statement.
*/
__try
{
......
......
exit(mainret); // you will come here if normal exit OR you
// handled any exception but still exited.
}
// This is CRTs final handler frame, here if exception not handled.
__except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) )
{
/*
* Should never reach here
*/
_exit( GetExceptionCode() );
} /* end of try - except */
}

 

[RB]

I know that, silly.

Oh well excuse me.

Are you trolling?

No I'm not trolling, I guess I am just that stupid. But never mind I don't need
input from such an ass.

 

[RB]

I looked up the meaning of trolling,
" In Internet slang, a troll is someone who posts inflammatory,
extraneous, or off-topic messages in an online community"
I did not know what it meant previously. In any case I certainly
was not trying to troll. The only thing I am guilty of is being
somewhat stupid in some areas. Possibly I over reacted to your
"silly" etc. on my post above. Who knows, I know you probably
don't care. That's all. Sorry for any wrong doing on my part.

 

[RB]

Found the answser to my error bug question.
Error: Is an undesirable deviation from requirements or Cosmetic .

Bug: Is an error found BEFORE the application goes into production or missing Functionality.

Defect :Is an error found AFTER the application goes into production or missing Requirement

 

[joe]

Found the answser to my error bug question.
Error: Is an undesirable deviation from requirements or Cosmetic .

Bug: Is an error found BEFORE the application goes into production or
missing Functionality.
Defect :Is an error found AFTER the application goes into production
or missing Requirement

I don't agree with those definitions, and they seem a bit "lofty".
"bug/defect", "tomato/tomoto", they mean the same thing to me. That one
tries to get all the bugs out before release doesn't factor into the
definition for me, nor does it make me want multiple terms based upon the
discovery time of the bug.

In C++, "errors" are expected and defined things (though probably occur
rarely) that one can manage with the exception machinery (or some other
facilities, perhaps that which one built themself). Errors are detectable
while bugs are not (but they can be flushed out by testing and reduced
via good coding practices). Robustness against errors is designed into a
program whereas robustness against bugs cannot be (bug-reducing practices
and processes are effective means though and OOB techniques are available
if required). Errors are thought about proactively while (specific) bugs
can only be thought about retroactively. The process after error is
defined and controlled whereas with a bug, the behavior is undefined.

So, what is a bug? A moth, of course. Therefor, always put a mothball in
with any shrinkwrapped software you ship.

 

[joe]

I looked up the meaning of trolling,
" In Internet slang, a troll is someone who posts inflammatory,
extraneous, or off-topic messages in an online community"

Well that's a definition I don't/won't use. Feigning not knowing
something to test someone else would be an example of trolling by my
definition. Another example would be purposely asking vague or
provocative questions just to instigate a flamewar. If the purpose is to
enrage or create chaos/commotion, then that would be trolling. If the
purpose is to obtain or convey on-topic information, I would not call it
trolling. (A more "modern" definition may note that not all trolling is
necessarily bad). Your definition seems more akin to public drunkeness.

I did not know what it meant previously.

Apparently, the "definitions" of it are all over the map rather than on
the same page.

In any case I certainly
was not trying to troll. The only thing I am guilty of is being
somewhat stupid in some areas. Possibly I over reacted to your
"silly" etc. on my post above.

I said "silly" because I would be quite aware of someone who I have gone
back-n-forth in detail about error handling and I'd expect you to know
that I would not think that someone else being referred to was actually a
reference to me, silly.