Yeni programcılar neden derleyici hata mesajlarını / çalışma zamanı istisna mesajlarını görmezden geliyorlar? [kapalı]

Bence hepimiz bunu gördük. Yeni başlayanlar, temel taslakları takip eden Stack Overflow ile ilgili sorular soruyor ...

Yapmaya çalışıyorum (hedefin belirsiz açıklaması) ancak işe yaramıyor / hata / istisna alıyorum. Lütfen yardım et!

Birçoğunun hata mesajını yapıştırmanın gereksiz olduğunu düşünmesi tuhaf değil mi?

Bunun psikolojisinin ne olduğunu merak ediyorum. İnsanların başlangıçta işe yaramaz olduklarını ve dikkat etmeye değer olmadığını varsaymalarını sağlayan hata mesajları hakkında ne düşünüyorsunuz?

Benim aradığım cevap değil “onlar hata mesajı anlamıyorum”. Bu, neden anlayabileceklerini kimseye söylemeyi düşünmediklerini açıklamıyor.

Bence asıl sebep, sıradan bilgisayar kullanıcılarının, programcı olmaya devam etmeleri durumunda bile, hatalar hakkında hiçbir şey yapamadıklarına inanmaları için şartlandırılmış olmaları. Bunu düşün. Programcı olmayan türler şifreli bir hata iletisiyle karşılaştığında ne yaparlar *? Onu okuyabilirler, ancak on üzerinden dokuz kez basitçe kovacaklar ve tekrar deneyecekler. Sadece sürekli olarak başarısız olursa, onu arayacaklar.

Programa nasıl öğrenmeye başladığı Bu nedenle, insanlar yok hemen onlar alıyoruz hata düzeltmek için nasıl faydalı bilgiler içerdiğini fark; ve evet, derleyici hataları eğitimli uzmanlar tarafından bile okunaksız olsa da (size bakıyorum, C ++ şablon metaprogramlaması), en azından genel bir başlangıç ​​noktası sağlarlar ve aynı hatayı birkaç kez gördükten sonra , buna neden olmak için ne yaptığınızı her zaman bilirsiniz.

* Dürüst olmak gerekirse, çoğu hata mesajı şu şekilde görünüyor: "Hata X2412: Frobnicatory bir karşılaştırma platformu kuramıyor: lütfen bandersnatch ayarlarını doğrulayın veya sistem yöneticinize başvurun."

Bence eğer gerçek bir başlangıçsa, bir hata mesajı olduğunu bilmeme ihtimalleri çok yüksektir. Sadece çalışmadığını ve bir hata olduğunu biliyorlar. Örneğin, Visual studio'da ekranın o bölümünü görmeyebilirler.

Temel olarak, sorunun ne olduğunu bulmak için ellerinde bulunan bilgilerin hangi bölümünün faydalı olduğunu bilmiyorlar. Bunu yaparlarsa daha iyi bir şans olurdu, kendileri düzeltebilirlerdi ve ilk başta sormazlardı.

Sorular sormanın ve sorun gidermenin öğrenilmesi gereken bir beceri olduğunu ve profesyonel geliştiriciler için, yeterince sık öğretilmeyen önemli bir beceri olduğunu düşünüyorum.

Tıpkı bu mesleğe ilk başladığınızda yazdığınız kodun, bugün yazdığınız koda göre daha korkunç olacağı gibi, sorduğunuz sorular bugün onlara sorma biçiminize göre daha korkunç olacaktır.

Başladığınızda, öğrendiğiniz tüm bilgiler ve bunlarla ilgili bir şeyler planlamayacağınız zaman bunalmak kolaydır, hangi bilgilerin neyin alakalı olduğunu ve nelerin olmadığını bilmek zordur. Bu, yeni başlayanların kendileri için sorunu kendi başlarına çözememe nedeninin büyük bir parçasıdır!

Bu, IRC'de, çok daha nadir bulunan Stack Overflow gibi çevrimiçi web sitelerinden daha fazla geçerlidir.

Bence arkasındaki sebep, özellikle bir kişinin problemleriyle ilgilendiğini ve onlara yardım etmeye istekli olduğunu bilirlerse, insanların kendilerini daha iyi hissetmeleridir. Böylece bir problemleri olduğunu söyleyerek başlıyorlar, ancak birileri onlara sormadan ayrıntılara girmiyorlar, çünkü başka türlü bir cevap alamayacaklarından korkuyorlar.

Bazen (derleyici hataları durumunda değil) bu davranış aslında mantıklı geliyor. Eğer büyük ve karmaşık bir sorunum varsa, kimsenin okumayacağı uzun bir açıklama yazmadan önce dinleyen birisinin olduğundan emin olacağım.

Çünkü derleyici hataları / istisnalar, düzeltmek için neyi yanlış yaptığınızı bilmenizi gerektirir. Onlar şeyleri görmezden gelen programcılar içindir, onları anlamayan insanlar için değil.

Ayrıca her zaman en açık olanları değiller. "Beklenmiyorsa" gibi bir hata, sezgisel değildir. “Ama eğer orada olsaydı” aceminin cevabı. Daha deneyimli bir programcı bunun bir önceki satırda noktalı virgül unuttuğunu gösterir .

Sadece yeniler olduğunu sanmıyorum. Derleyici hatası aldıklarında sadece satır numarasına bakıp yıllarca süren deneyime sahip iş arkadaşlarım var, sonra gerisini kendileri anlamaya çalışıyorum (genellikle "hadi parantez ekleyelim" veya "hadi bunu kaldıralım" iki ifadeye "".

Benim şüphem, bunun gerçekten dilin kurallarını derinlemesine anlayamamasından kaynaklanıyor, bu nedenle hatanın genel olarak yoğun tanımının pek bir anlamı yoktur. expression must be a modifiable lvalueBir değerin ne olduğunu gerçekten bilmiyorsanız oldukça işe yaramaz bilgiler gibi görünüyor .

İnsanların başlangıçta işe yaramaz olduklarını ve dikkat etmeye değer olmadığını varsaymalarını sağlayan hata mesajları hakkında ne düşünüyorsunuz?

Benim için, Windows 95 yazılımını genellikle 150 satır onaltılık satırla sona eren, tamamen aşılamaz hata mesajları ile çökerten bir gençlikti.

Ne zaman 40 satır derleyici pisliği ve Hazırda Beklet hataları içerecek ve aralarında çok iyi saklanmış güzel bir şifreli Java yığın izlemesi elde ettiğimde aynı deneyimi yeniden yaşamaya başladım.

İnsanların hata mesajlarını yok saymasının ve yığın izlerinin nedeni genellikle hata mesajlarıdır ve yığın izleri, sorunun karmaşıklığına kıyasla orantısız şekilde karmaşıktır. Yarı-kolonu kaçırdığımda ekranım boyunca 150 çizgi saçmalığını yıkamak için hiçbir sebep yok.

Linux'ta Junior Sysadmins için bazı kurslar ve PHP ve Mysql ile programlama dersleri veriyorum. PHP'deki öğrencilerin büyük çoğunluğu bir hata olduğunu biliyor çünkü ekranda çirkin mesajı görüyorlar. Ama okuyamıyor gibi görünüyorlar. Genellikle bana bir şeyin çalışmadığını söyledikleri zaman ekranlarına giderim, ekrandaki hatayı okurum, okumalarını söylerim, hataya not edilen dosya ve satırı vurgularım ve oraya bakmalarını söylerim. Hatayı düzeltirler, ancak başka bir hata ortaya çıktığında, aynı prosedür uygulanır ... iç ...

Linux kursu için bazen hatayı bile fark etmezler. Bazı komutlar girerler, bazı satırlar ekranda belirir ve bir sonraki komutla devam eder. Bazı komutlar daha sonra en sonunda bir şeyin işe yaramadığını ve ellerini kaldırdıklarını fark ettiğinde, yukarı çıktım, konsolu yukarı kaydırdım ve hatalı parametrelerden veya herhangi bir şeyden dolayı bir hatayla çıkılan bir komutu işaret ediyorum. Yüzleri: sürpriz. Bu yüzden linux öğrencilerim için kolay olan kısım, bir hata ortaya çıktığında fark etmelerini sağlamaktı, bunun gibi bir hata ortaya çıktığında farklı hale getirmek için bash komutunun bazı modifikasyonlarını kullanmaktı . Şimdi, gördüklerinde hata mesajını okumalarını sağlayın, bu farklı bir savaş (PHP öğrencileriyle aynı)

Hata kodları hakkında düşünmeye alışkın olmadıklarına ve kendilerine vermeleri gereken yere geldiklerinde, sorunu tamamen açıkladıkları gibi hissetmeye başladığını ve bu nedenle durup düşünme konusunda daha az olasılıkla olduklarına inanıyorum. ek bilgi vermelidirler.

Bir soru sormak birkaç aşamadan oluşur ve bunlar en mantıklı bir şekilde bu sıraya göre düzenlenir:

1. ne yaptığını tarif etmen gerek
2. Bunu nasıl yaptığını açıklaman gerek.
3. başarısız olduğunda ne olduğunu açıklamanız gerekir (veya nasıl başarısız oldu)
4. ölüm sonrası raporu vermelisin

Ölüm sonrası rapor, hata mesajının nerede olacağıdır ve en sonundadır. Yeni başlayanlar bu noktaya geldiklerinde, sorunlarını açıklamadaki zihinsel zorluğun sonunda olurlar ve bir şeyi kaçırmaları daha muhtemeldir (yeni başlayanlar için, aşırı bilgi sorunu var). Dahası, bu noktada, problemin tüm yönlerini tanımladıklarını hissediyorlar ve hata kodlarını hatırlamalarını engelleyen geçmiş alışkanlıkları var: sonuçta, diğer yaşam alanlarının hata kodları yok, bu yüzden alışkın değiller. onları düşün.

Ayrıca, hata kodlarını hatırlasalar bile, gerçek kullanım için fazla şifreli görünebilirler. Sadece 034982 hatası nedir? Bu gerçekten kimseye bir şey ifade ediyor mu? Ve gerçekten ne yaptığımın, nasıl yaptığımın ve nasıl başarısız olduğumun detaylı açıklamasına bir şey ekliyor mu? Somurtkan bu bilgi kendisi için duruyor.

Çünkü çoğu dil için, çoğu derleyici / çalışma zamanı mesajı bir anlam ifade etmiyor. (Özellikle C ++ ve Java sana bakıyorum!) Hataları doğru yapmak bir dil tasarımcısının öncelikler listesinde oldukça düşük olma eğilimindedir. Doğru işe yarayan işleri yapmak genellikle daha büyük bir önceliktir ve küçük ayrıntıları parlatma ile uğraşmazlar.

Delphi'de çalışmaktan hoşlanmamın sebeplerinden biri de bu. Tüm dil, hatalar da dahil olmak üzere küçük ayrıntılara dikkat çekiyor. Derleyici mesajları anlamlı. Çalışma zamanı hata mesajları mantıklı. Yığın izleri anlamlıdır. Şimdiye kadar çalıştığım en hata ayıklama en kolay dili, onu yapan şeylerden biri.