CakeAlexS
In the world of software anything that causes a crash is a bug. However in the world of software it could be argued that it is a rare use case and would be minor priority (although I personally would disagree with this as any stability issue is a major IMHO).
 
Although if the steps turned out to be not reproducible then the bug would just be closed or more info would be required. Either way a bug report would need to be created in order for it to get in front of a member of the QA team.

Well... I'm not a code talkin' dude but the term "bug" comes from the old analog tube and circuit computing days when actual insects would get into the electronics and fry things out screwing up operations. My understanding is that in the software realm the "bug" is an improperly placed/written or missing piece of code. So if the function is one that isn't intended usage can it really be considered a bug?
 
Seriously I don't know. Werds are funny thingz. ;-)

If "my finger slipped off the mouse button while my selection was moving over top of the take lanes' "master" track." is considered a bug then a guy's hand slipping off a steering wheel and causing an accident is a defect in the automobile.  Silly and an exaggeration but not entirely off.

Regardless of how you want to define the term "Bug", I think your average programmer would consider any error that is not properly trapped causing a crash to be highly undesirable, and would accept responsibility for handling it as a programming problem even if it was precipitated by an inadvertent/unanticipated/unsupported action of the user. By this time, there are probably thousands of such actions that have been identified (whether anticipated by programmers or reported by testers or users) and handled.
 
But this one needs a better recipe, because it's clearly not as simple as just dropping any selection of clips from lanes on the parent track in any project.

Hehe... the new thread already sprouted "new hairs!"
 
My interpretation of the OP is "SONAR should handle its own exception errors." The example is merely that.
 
When a program executes "something" it can be told to do something it cannot, and will throw an exception error... if there is not something internal to the program to intercept (i.e. "handle") that error, the program can crash. Simple handlers can typically say "on exception, do nothing," but this often confuses the user more.
 
As far as the OP is concerned, SONAR handling its own exceptions is a valid point... (in an ideal world) if X3 handled all of its own exceptions, then any crash has to be "something else," but X3 can only control its "own territory" even then.

@Sanderxpander - regarding your following quote: " a hard crash means something occurred that the bakers hadn't foreseen and the program doesn't know what to do"
 
I respectfully disagree on your conclusion on hard crashes being necessarily the fault of Sonar.  There are many many reasons for crashes, including background services, hardware issues, BIOS issues, device drivers, device firmware, Windows issues, antivirus software, other conflicting applications, settings mismatches between audio interfaces and Sonar, plugging an audio interface meant for USB 2 into a USB 3 port, some 32-bit plugins freaking out in a 64-bit Sonar environment, errant user 'tweaking' of the system, etc.
 
Just because Sonar is running does not mean that at any particular time it has control - many times crashes occur with 32-bit plugins in control in a 64-bit Sonar, for example.
 
This of course does not mean to suggest that there are not crashes that occur that ARE caused by Sonar - and that is not what I was trying to say - I am just pointing out that there a great many additional reasons crashes occur than solely caused by Sonar.
 
Bob Bone
 

> So if the function is one that isn't intended usage can it really be considered a bug?

Tell that to a pilot of a plane, sorry about the crash you pressed the button at the wrong time in  a use case we considered invalid. Fact is any crash can be considered a bug not a feature. Think about your next session with U2, the Edge wouldn't be pleased if his guitar track got accidently wiped because you didn't save it before you dragged the clip and it crashed, and he would probably refuse to tell you what is under his hat for the entire day. Yes Sonar should be handling its own exceptions assuming it is Sonars fault and not third party code. And Sonar should be doing its very best to trap third party errors (within reason, this can be almost impossible to do) by sandboxing as much as possible.
 
(Mind you all you would need to do is loop the first bar of his guitar say 40 times and he probably couldn't tell the difference).

robert_e_bone
@Sanderxpander - regarding your following quote: " a hard crash means something occurred that the bakers hadn't foreseen and the program doesn't know what to do"
 
I respectfully disagree on your conclusion on hard crashes being necessarily the fault of Sonar.  There are many many reasons for crashes, including background services, hardware issues, BIOS issues, device drivers, device firmware, Windows issues, antivirus software, other conflicting applications, settings mismatches between audio interfaces and Sonar, plugging an audio interface meant for USB 2 into a USB 3 port, some 32-bit plugins freaking out in a 64-bit Sonar environment, errant user 'tweaking' of the system, etc.
 
Just because Sonar is running does not mean that at any particular time it has control - many times crashes occur with 32-bit plugins in control in a 64-bit Sonar, for example.
 
This of course does not mean to suggest that there are not crashes that occur that ARE caused by Sonar - and that is not what I was trying to say - I am just pointing out that there a great many additional reasons crashes occur than solely caused by Sonar.
 
Bob Bone
 

Sweeping generalizations are always wrong. :)
I agree with you that there are many places errors can occur. That doesn't mean Sonar shouldn't be able to deal with these a little better. It isn't the soundcard driver crashing even if it does tell Sonar something unexpected, it isn't Windows hanging, it isn't toasted RAM. I don't think 32-bit plugs should be able to crash any version of Sonar to be honest. Not work, sure, but crashing, no.
Perhaps these are very unrealistic demands for such a complicated program with so many features. But generally speaking (here we go again) I have seen a little too many random things crashing Sonar on my system while Ableton both (8 and 9) has been solid as a rock with the same plugs and soundcard.

Sorry i brought up the bug thought as a sidenote.  I think what got lost is that i agreed wit hthe OP that it should be addressed regardless of what you ant to cal it.

> Perhaps these are very unrealistic demands for such a complicated program with so many features
 
If everybody managed to trace the bug so they could reproduce the error on demand, wrote down the steps exactly and threw it into Cake problem reporter then no, not unrealistic at all.

While I agree that this might be useful, firstly it doesn't seem always reproduceable. I have reported the ones that were. However ultimately I don't think it's the responsibility of the end user to meticulously trace bugs. That's the responsibility of the developers or, possibly, the beta testers.