Okay, this is one of those things that might happen to anyone while working in haste with take lanes. After splitting up a take into several bits (for the purposes of treating those bits with differing effects) I grabbed some of those bits and drag (heading for a new track) and my finger slipped off the mouse button while my selection was moving over top of the take lanes' "master" track.
 
Result: hard crash.
 
Yes, this is something I would normally NOT do. I didn't set out to do it, but when it happens, I would expect any software to be a bit more forgiving and handle this type of situation. Either automatically add a new take lane (same behavior as dragging an audio file from Windows Explorer into a blank area of Sonar) OR throw up a dialog saying, "You can't do that! Stop it right now!" and then patiently wait for me to screw my brain back on straight and try again.
Know what I mean?
 
Just in case in needs to be said...
I really am very grateful for Sonar X3. It's by far the most well-though-out software I've used since about 1989. I've tried very hard not to complain about the little foibles I've encountered and will continue to make the effort.
 
The above statement of complaint was made in the spirit of doing my bit to make Sonar an ever-better application.
Thanks for reading.

I agree that Sonar error handling hasn't been great for me either. Most of the time it's quite stable but there have been too many hard crashes for my taste - a hard crash means something occurred that the bakers hadn't foreseen and the program doesn't know what to do. Proper error handling would do what you suggested and say "BING - you can't do that" or something.
Not only does it not do that, but 80 percent of the time the crash handler/error reporter itself freezes!

It also seems to me that it's some projects that just become "crash prone" and others stay fine.

> a hard crash means something occurred that the bakers hadn't foreseen and the program doesn't know what to do

Exactly (assuming it isn't drivers or plugins that is the cause), so you need to log an issue if you are able to reproduce the exact steps every time as it is hard for anybody to test every single scenario, it would be nice if you could please post the issue number here. cheers:
http://www.cakewalk.com/support/contact/problemreport.aspx
 

+1, error handling within SONAR itself could be improved. Plug-ins, etc. are a more difficult beast, but when exceptions are thrown by the program itself, they should be handled more effectively.

Yanno... I never really thought about it in those terms before but yeah... a popup/warning of an illegal function would be better than a hard crash and losing the work. I wouldn't even mind crashes so much if it didn't sometimes totally wipe my progress to BEFORE my last saves. Like say I'm diligently hitting the save button and experience a crash when I reopen those saves don't show up. Even if a do a Save As without closing and reopening the project I can't return to that point (but sometimes I can reopen the project but not through the "Open" dialog which I leave on because it won't show up on the list. I have to close the dialog and use File > Open then find the Save As version).
 
I get very few hard crashes though and many times it's because I'm doing something too quickly or being a dumbass but still it's a pain.
 
The only downside though to the convenience of Sonar just not allowing the program to crash and providing a popup is that they would get far less problem reports and not be able to fix those issues. I'm assuming that type of thing might be a pain to embed into the program too and might cause other issues. Frankly things seem to be reasonably stable for the moment so the less fiddling around with the core guts the better. I'm mildly concerned about what the new video features will do but I'm going on the premise that we already have two stable builds to fall back on each of which have very specific problems that are known so in the rare eventuality one of those issues pop up on a user rolling back or updating to the other should get the user to a workable build.
 
The BIG tests for me with X3 are going to be editing a large project and doing multi track time correction/stretching with audiosnap. If those two things work (and I guess in the case of audiosnap if it just works BETTER) then I'll be a happy beep. I've done a bit of tracking and already some of my problems there are gone. Mixing has never really been a problem as far as crashes and bugs in X2 unless I don't have my hardware settings right. I did not experience any significant problems or glitches mixing Beeps Creep in X2.

mettelus
+1, error handling within SONAR itself could be improved. Plug-ins, etc. are a more difficult beast, but when exceptions are thrown by the program itself, they should be handled more effectively.

No bugs shouldn't be fixed ! :) I like them....
(only kidding)...
The point is though we should always be using that bug report form in reproducible scenrios.

Maybe it's me, but I don't consider something like that a bug. To me a bug has to be something that goes awry as part or normal operating process. When one does excatly what they were intending to do and get errors,crashes, malfunctions, etc. The OP clearly stated he mad a mistake and his concern was that Sonar should handle such user errors more elegantly.  I happen to agree with the OP but would hardly consider this a bug.

FWIW, dragging and dropping from a lane to the parent track is not a disallowed operation (double-negative intended). Depending on how many lanes you drag from and how many lanes are available, dropping clips into the parent will overwrite/slip-edit clips in other lanes out of the way, starting at T1, and/or create new lanes. In any case, I can't replicate the crash.
 
 

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.

dubdisciple
Maybe it's me, but I don't consider something like that a bug. To me a bug has to be something that goes awry as part or normal operating process. When one does excatly what they were intending to do and get errors,crashes, malfunctions, etc. The OP clearly stated he mad a mistake and his concern was that Sonar should handle such user errors more elegantly.  I happen to agree with the OP but would hardly consider this a bug.

I'm not quite certain what OP described because I'm not that familiar with the new lanes/parent track relationship but yeah... if it's not supposed to be done then it's not a bug when things go awry. Probably shouldn't let you do it in the first place but not really a bug. It reminds me of the crash I had when I was first poking around X3. I ahd done a bunch of stuff just to check things out and wanted to get back quite a few steps and instead of using the History menu I just hit Ctrl + Z a bunch of times really quickly and got a hard crash.
 
The problem reporter came up but really what would it tell the bakers? That I'm an idiot? I think they already know that. lol
 
;-p